When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next fiscal year using `date_from + 1 year` instead of querying the actual next fiscal year. This causes entries for the months between the wrong and correct FY start (e.g. January-April) to be skipped entirely.

Step to reproduce:
- Create a company with a fiscal year starting in May (e.g. May 1st 2025 to 31st December 2025)
- Create an asset with a start date in the 1 December 2025, with a 24 months duration and degressive method
- Compute the board and observe that entries from January to April 2026 are missing

Fix the FY boundary detection in _recompute_board to query the fiscal year containing the day after the current period end, revert the effective_start_date logic in _compute_board_amount that was masking the root cause, and move the prorata date clamping to _create_move_before_date where it is needed for disposal.

opw-6016834

Forward-Port-Of: odoo/enterprise#113521

**Steps to reproduce:**
* Install  `stock` module.
* Go to  Settings and enable: 
     * Storage Locations (Warehouse).
     * Batch, Wave & Cluster Transfers.
* Create a Product and set its on-hand quantity to 60.
* Go to Inventory → Configuration → Operation Types and create a new operation type:
     * Set Type of Operation to Internal Transfer.
     * In the Barcode App tab, enable Group batch lines.
* Go to Inventory → Operations → Internal Transfers and create a new transfer:
     * Select the newly created Operation Type.
     * Add the created Product with quantity 4.4.
     * Mark the transfer as To Do.
* Create another Internal Transfer with the same configuration:
     * Select the same Operation Type.
     * Add the same Product with quantity 48.8.
     * Mark the transfer as To Do.
* Open the Internal Transfers list view.
* Select both created transfers.
* Click Action → Add to Wave Transfer.
     * Choose A new Wave Transfer and confirm.
* In the popup, select both transfers and add them to the wave.
* Open the Barcode application.
* Open the created operation and select the Batch on the right side
to open the wave transfer in the barcode interface.

**Observed behavior:**
- The grouped line quantity is displayed as 53.99999996 instead of
the expected value(53.2).

**Cause:**
- When the Barcode app loads data,` _createState()` is executed,
which calls `groupLines()`.
- Inside this method, quantities are aggregated using standard
JavaScript floating-point addition:

https://github.com/odoo/enterprise/blob/08d0a7f480046bb489ca69e7b3535e99cb20eee5/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L204-L205

- Since JavaScript stores numbers as binary floating-point values,
decimals like 4.4 and 48.8 cannot be represented exactly.
Repeated additions accumulate precision errors, producing results
like 53.99999996 instead of 53.2.

**Fix:**
- Aggregate quantities using `formatFloat` with the barcode precision
before converting them back to floats

- `formatFloat` rounds the value according to the configured precision
of the barcode model, ensuring the intermediate result is normalized
after each addition. Converting the formatted value back with
`parseFloat` guarantees the stored number respects the expected
decimal precision and prevents floating-point accumulation errors.

---
opw-5932329

Steps to reproduce:
----------------------------------------
1. Install the Project module with the demo data
2. Go to Task > All Tasks> Kanban View
3. Move all the tasks to any one stage except one task
4. Now move that one task and quickly press (Alt + 1) to exit

Observation:
----------------------------------------
Traceback occurs:
```
Uncaught Promise > Component is destroyed
Occured on localhost:8069 on 2026-03-10 09:47:35 GMT
Error: Component is destroyed
```

Issue:
---------------------------------------
When dragging a record between groups, `moveRecord` calls `_resequence()`, which checks `canResequence()`
https://github.com/odoo/odoo/blob/f86baa6ba1c915145dbfe43b67de0eff13959e91/addons/web/static/src/model/relational_model/dynamic_list.js#L311-L314

For Project Tasks, `canResequence()` returns `true`, so the full async chain runs:

1. `rpc('/web/dataset/resequence')` — raw, unprotected call (succeeds)
2. `orm.read()` — protected by `useService` wrapper

If the user navigates away (ALT+1) between step 1 and step 2, the component is destroyed, and `orm.read()` throws Error('Component is destroyed') via `_protectMethod`

https://github.com/odoo/odoo/blob/f86baa6ba1c915145dbfe43b67de0eff13959e91/addons/web/static/src/core/utils/hooks.js#L106-L110

This error propagates up unhandled.

Solution:
---------------------------------------
Override `sortRecordDrop` in `ProjectTaskKanbanRenderer` to catch the 'Component is destroyed' error. Since the resequence RPC has already succeeded server-side, the follow-up `orm.read()` failure is harmless, the component is being destroyed anyway.

opw-5932085

Upon chart reload, accounts will not be updated (except for tax_ids), but tax groups are. If a tax group was changed to relate to a different account and this account was re-purposed (e.g. account_type changed from an incompatible to a compatible type, the fact that the account is not updated will trigger constraints in the tax group when it is written. IOW, if the purpose of an account is not changed, its use should not be changed either.

E.g.: 1f4710deb206736cd71580d8fd95552d9b7c8014 changed the value of `tax_payable_account_id` on tax group `tax_group_cofins_incl_goods` to `account_template_202011005` and the same commit changed the value of `account_type` on `account_template_202011005` from `liability_non_current` to `liability_payable`, triggering `_constrains_payable_receivable_account` (in 19.2: https://github.com/odoo/odoo/blob/e00dd21880c3c4e5c22d65567c700e02541f7259/addons/account/models/account_tax.py#L68).

So here, we skip the update of relations to accounts on tax groups, if the account already exists.