- Added new fields to res.company to handle key, certificates and session numbers
- Added new fields to account.move to track KSeF status, session, reference number, attachments, errors.
- Updated the frontend view of the move and the settings. Some fields are debug-view only.
- Implemented the sending method with `account.move.send`, storing the xml attached to the move.
- Implemented the APIs to communicate securely with the KSeF
- Implemented the Check Sending and Download UPO functionality
- Implemented the rendering of the FA(3)-compliant XML structure.
- Implemented a cron to update invoice KSeF statuses.
- Implemented locking so cron and manual don't mess up with each other.
- Set as `auto-install` for those who have the Polish localization.
- Wrote minimal tests for basic use cases (to be expanded).
- Added `neutralize.sql` script to avoid leaking sensitive data when copying a database for support
- Added module to `.weblate.json` to make this i18n-able

Task [link](https://www.odoo.com/odoo/project.task/4728713)
task-4728713

Problem:
- In version 17, event records linked to a sales order can be automatically set to ‘open’ immediately after the sale. This makes the wizard editor less useful (the data provided is not used for the record that is already confirmed) and notifications go to the sales partner instead of the actual assistant.

Current behaviour:
- Confirmed orders automatically confirm attendees, reducing the value of the wizard step and sending emails to the wrong recipient.

Expected behaviour:
- Paid attendee registrations created from Sales should remain in “draft” until attendee details are provided.

Solution:
- Do not set ‘state=“open”’ for payment records created from a sale involving
  the data wizard for records. Ensure they remain in “draft”.
- Confirm registrations once attendee details are present.

Advantages:
- Restores the usefulness of the attendee editor: confirmation occurs after data entry, so notifications are directed to the attendee, not just the sales partner.
- Meets functional expectations for administrative control and proper recipient targeting.

Tests to reproduce the error:
- Create quote with payment entry
- Confirm SO
- Enter attendee details and confirm
- Registrations change to ‘open’ and a confirmation email is sent to the order partner and not to the registered attendee.

@Tecnativa TT58160

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

Forward-Port-Of: odoo/odoo#230500

**Issue**
In subcontracting, if a BOM is modified after the creation of a PO, then modifying the move quantity of the associated receipt can lead to inconsistency between move and move line quantities.

**Steps to reproduce**
- Create a subcontracting BOM of a final product using 1 component product
- Create a PO of the final product for a quantity of 10 and confirm it
- Modify the BOM to use 2 component products instead
- Go to the receipt of the PO and modify the quantity to 2 and validate it
- Click on the move line of the receipt -> The displayed quantity is 10 instead of 2

**Cause**
Setting the quantity triggers this line:
https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/stock_move.py#L78-L78 
which calls:
https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/stock_move.py#L107

Since the BOM has been modified, a `consumption_issues` is detected and `_update_finished_move()` won't be called:
https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/mrp_production.py#L86-L89

And since the returned action is not used when calling `subcontracting_record_component`, `_update_finished_move()` won't be called later neither, which is the method responsible for updating the move line quantities:
https://github.com/odoo/odoo/blob/c496235b9520b2a33040174974de7d37e74b0580/addons/mrp_subcontracting/models/mrp_production.py#L142-L146

**Solution**
Since the consumption issue actions are ignored in this case, just skipped it and avoid inconsistencies.

opw-5493577

Forward-Port-Of: odoo/odoo#245065

### Issue:
Attendances overlapping on two days are ignored for hourly accrual plans based on attendances.

### Steps to reproduce:
- Install 'hr_holidays_attendance'
- In Time Off > Configuration > Accrual Plan, create a new plan
	- Based on worked time
	- Hourly rule
	- Attendances as Source
- In Management > Allocations, create an allocation for an employee using the new accrual plan
- Create an Attendance for this employee in the period of the Accrual Plan
	- Check-in at 22pm for example
	- Check-out at 7am
- Run the cron "Accrual Time Off: Updates the number of time off"
- The Allocation ignores the worked time from the attendance

### Cause:
`_get_accrual_plan_level_work_entry_prorata()` is called on each day of the accrual period. So `start_dt` is `datetime.datetime(2026, 1, 2, 0, 0)` and `end_dt` is `datetime.datetime(2026, 1, 3, 0, 0)` for example. This means that the search will always excludes attendances overlapping on two days.

https://github.com/odoo/odoo/blob/26f3026ed45cc409cd7f67fa219d44f1adbac9b7/addons/hr_holidays_attendance/models/hr_leave_allocation.py#L79-L83

### Solution:
To count the attendances on several days, we need to split these attendances by day because `_get_accrual_plan_level_work_entry_prorata()` is only called with an interval of one day from midnight to midnight.

First we get all attendances overlapping with the day by changing the domain in the search.

Then we could simply take the difference between `max(attendance.check_in, start_dt)` and `min(attendance.check_out, end_dt)` but we also need to remove the lunch breaks (they were not counted in `attendance.worked_hours`). 

This would mean duplicating the code present in `_compute_worked_hours()`. To avoid this we create a new method for `hr.attendance` named `_get_worked_hours_in_range()`. That returns the number of hours worked due to this attendance in a given time frame. 
This new method can be used in both cases to get the needed value.

opw-5172669

The _add_consolidated_invoice_base_lines_vals method computed the gross subtotal using `price_unit * quantity`. When taxes are configured as "Included in Price", `price_unit` contains the tax-included amount, but `total_excluded` (used for the discounted amount) is tax-excluded.

This caused the tax amount to be incorrectly reported as an AllowanceCharge (discount) in the MyInvois XML, because:
  discount_amount = price_unit * qty - total_excluded
                  = tax_included - tax_excluded
                  = TAX AMOUNT (not a discount!)

Example: Product priced at 110 MYR with 10% tax included:
- price_unit = 110 (tax-included)
- total_excluded = 100 (tax-excluded: 110 / 1.10)
- discount_amount = 110 - 100 = 10 ← incorrectly reported as discount

refs:

The cac:AllowanceCharge element in UBL is specifically for discounts and surcharges, NOT for taxes. According to the Peppol Malaysia e-Invoice specification:

https://docs.peppol.eu/poac/my/pint-my-sb/bis/#_allowances_and_charges

https://docs.peppol.eu/poacc/billing/3.0/codelist/UNCL5189/ (For this case we are interested in code 95)

Steps to Reproduce:
1. Configure a tax as "Included in Price" with Malaysia tax type
2. Create a product with that tax.
3. Create POS orders without any discount
4. Generate consolidated invoice and XML
5. XML incorrectly shows <cac:AllowanceCharge> with tax amount as discount

The fix uses `raw_total_excluded / discount_factor` (always tax-excluded) instead of `price_unit * quantity` (may be tax-included), consistent with the parent method:
https://github.com/odoo/odoo/blob/d645361a95037ac580d55e80bcb61d1eeb293efd/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L1846-L1876

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

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

Link to Avalara (Avatax) documentation:
https://developer.avalara.com/api-reference/avatax/rest/v2/models/LineItemModel/

Expected Behaviour:
The itemCode sent to the AvaTax API should be 50 characters or fewer
to comply with Avalara's field length constraints.

Actual Behaviour before the Fix:
When an itemCode exceeded 50 characters, the system attempted to send
the request as-is. This resulted in the AvaTax API returning an error,
causing the transaction or tax calculation to fail.

Behaviour with the Fix:
The system now ensures that the itemCode adheres to the 50-character
limit before the API call is made, by trancating the code to the
first 50 characters if it exceeds 50 characters. This prevents API
rejection and ensures successful tax processing for items with
long identifiers.

Steps to reproduce:
1. Create or select a product/item with a reference (or barcode if
   using UPC) longer than 50 characters.
2. Trigger an action that calculates tax via the AvaTax
   integration (e.g., creating an invoice or updating a line item).
3. Observe the API response.

- Before fix: API returns a validation error regarding the
  itemCode length.
- After fix: Request is successful as the itemCode is
  properly handled/validated.

opw-5406451

### Issue:
Due to this issue, `coupon_ids` which are never used are still shown in loyalty coupons history which is confusing for users.

#### Steps to reproduce:
1- Create two promotions:
   - Promo A: 10% discount
   - Promo B: 20% discount

2- Create a SO and add a line. Then confirm the SO.
3- Click on `Reward` button.
4- A dialog should show both promos. Discard the dialog.
5- Navigate to `Discount and Loyalty`.
6- Open Promo A and B and you can see both have lines with
   `coupon_id.order_id` = `created SO` which is confusing. `Issue 1`
7- Navigate back to SO. Click on `Reward` and select Promo A, apply.
8- Navigate to Promo B. As you see the the `coupon_id` related to
   the SO is still there. `Issue 2`

### Cause and Fix:
This is due to unlinking `coupon_ids` only in SO confirm action, causing this issue on already confirmed SOs:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/sale_loyalty/models/sale_order.py#L132-L136

We can fix this issue by `unlinking` the `coupons_ids` when a reward is applied or the dialog is discarded.

However there are 2 limitations:
1- The view needs to be updated. Otherwise, `coupon_ids` will not be deleted upon clicking on `discard` button. However the fix is still stable.
2- What if the dialog is closed with the cross button or the tab is closed without selecting a reward? In that case the issue will still persist.

To fix these issues, we can show only used `coupon_ids` in `loyalty_coupon_id` list view. However that cannot be done in stable as it requires `use_count` to be stored.
NB: With some complex filters this also could be fixed on stable but not worth it.

opw-5424753

When pos_event was added, a difference in behavior with the existing registration flow in website_event was missed. When answering an 'identification question' (name, email, phone, company_type) with the 'once per order' enabled, the values should be used and propagated directly on the created event.registration records, with precedence over other answers given to individual questions (not once per order)

STEPS
=====

1. Create a new event with name, email questions, once per order ticked.
2. Go to POS (reload data if needed)
3. Register and answer both questions
4. Continue the pos flow until both registrations are created
5. Go to backend > your event > registrations
6. You can see that even if the answers are propagated in the o2m field registration_answer_ids, which is expected, the attendee's name and attendee's email fields are empty. They should contain the values of step 3.

FIX
===

Align the website_event flow and precedence of OPO questions over
individual answers in pos_event. Now, the first non-null answer of an OPO
question will be used for each of the question_type values listed above,
if any, over answers to individual questions.

Also align the fact that after OPO answers, precedence should be given
to the first non-null answer to a given question type for identification
questions, and not the last as it is currently.

Task-4919080

### Issue:
Attendances overlapping on two days are ignored for hourly accrual plans based on attendances.

### Steps to reproduce:
- Install 'hr_holidays_attendance'
- In Time Off > Configuration > Accrual Plan, create a new plan
	- Based on worked time
	- Hourly rule
	- Attendances as Source
- In Management > Allocations, create an allocation for an employee using the new accrual plan
- Create an Attendance for this employee in the period of the Accrual Plan
	- Check-in at 22pm for example
	- Check-out at 7am
- Run the cron "Accrual Time Off: Updates the number of time off"
- The Allocation ignores the worked time from the attendance

### Cause:
`_get_accrual_plan_level_work_entry_prorata()` is called on each day of the accrual period. So `start_dt` is `datetime.datetime(2026, 1, 2, 0, 0)` and `end_dt` is `datetime.datetime(2026, 1, 3, 0, 0)` for example. This means that the search will always excludes attendances overlapping on two days.

https://github.com/odoo/odoo/blob/26f3026ed45cc409cd7f67fa219d44f1adbac9b7/addons/hr_holidays_attendance/models/hr_leave_allocation.py#L79-L83

### Solution:
To count the attendances on several days, we need to split these attendances by day because `_get_accrual_plan_level_work_entry_prorata()` is only called with an interval of one day from midnight to midnight.

First we get all attendances overlapping with the day by changing the domain in the search.

Then we could simply take the difference between `max(attendance.check_in, start_dt)` and `min(attendance.check_out, end_dt)` but we also need to remove the lunch breaks (they were not counted in `attendance.worked_hours`). This would mean duplicating the code present in `_compute_worked_hours()`. To avoid this we create a new method for `hr.attendance` named `_get_worked_hours_in_range()`. That returns the number of hours worked due to this attendance in a given time frame. This new method can be used in both cases to get the needed value.

opw-5172669

Forward-Port-Of: odoo/odoo#246270

A recent PR improved the performance of the General Ledger Report XLSX export in v17 because it used to raise memory errors and crash when there were too many lines.

Task: 5476982
PR: [103329](https://github.com/odoo/enterprise/pull/103329)

After this change, we now search for the accounts to include in the file with `_get_accounts_with_move_lines`.

Some accounts are filtered out if the points below are all true:
1. The `account_type` != 'equity_unaffected'
2. The `account.include_initial_balance` is FALSE (or NULL after a recent fix)
3. There are no amls with a date within the date range of the report

This last point is problematic, the general ledger should include accounts with amls if they are dated in the financial year corresponding to the `date_from` value, unless the `general_ledger_strict_range` option is activated. We do not list the journal entries in the report if their date precedes the starting date of the report, but we still perform a sum of their balance/debit/credit with `_get_query_sums()`.

Steps to reproduce the issue:
1. Create a fresh db in v17 and install the accounting app with demo data
2. Navigate to the General Ledger and select tomorrow as a starting date
3. Export the report as an XLSX file
4. Some accounts are missing in the XLSX file and the report is unbalanced

Tickets:
opw-5868482
opw-5787298

Forward-Port-Of: odoo/enterprise#105871