This commit adds 4 attachments to the Latvian tax report
and an XML export for the tax report (including the attachments).

The attachments are the following
- PVN 1-I: domestic purchase / import
- PVN 1-II: EU purchase
- PVN 1-III: domestic sales / export
- PVN 2: EU sale

The attachments give more details for the tax report.
The lines of the attachments are "transactions"
A "transaction" is identified by the move and the transaction type or document type.
The transaction type is given via a tax tag (see community PR).
- PVN 1-I: transaction type, move
  - Small transactions (< 150€) are aggregated separately under transaction types 'V' or 'T'
    independently of the move
  - 'V': All small transactions of a partner in case the total of all their small transactions reaches 150€
    - There is max 1 line per partner
  - 'T': All small transactions that are not grouped under some 'V' line
    - There is max 1 line like this; it has no partner information
- PVN 1-II: transaction type, move
  - Small transactions (< 150€) are aggregated separately under transaction types 'V' or 'T'
    (like PVN 1-I)
- PVN 1-III: document type, move and line in the main tax report
  - All transactions with (document) type 'X' are aggregated on a single line
  - Small transactions (< 150€) are aggregated separately under document types 'V' or 'T'
    (like PVN 1-I)
  - The line in the main tax report is ignored for 'X' and small transactions
- PVN 2: transaction type, move
  - No aggregation is performed here

Only account move lines that are tagged with a transaction type (1-I, 1-II, 2)
or a relevant tag for the main report (1-III) are shown in the reports.

The tags `Rep` and `C (car)` only take 40% and 50% respectively of the
base amounts. The tax amount is assumed to be split correctly.

task-4251184

Forward-Port-Of: odoo/enterprise#84135

similar to https://github.com/odoo/enterprise/pull/120566/changes/b5b6589c9c91980e41d025ae74082af63907debc

When generating an offer from the recruitment application and signing it, the applicant's email address is incorrectly displayed.

### **Steps to Reproduce:**
1) Install sign, recruitment, hr_contract_salary
2) Create an new application and add basic detail like name and email as
   (path and path@test.com)
3) Generate offer and sign with all the required signer. 
4) Open the application form view and open the certificate.

### **Observed Behavior:**
Email is not set correctly in the generated certificate (appearing as john@example.com).

### **Expected Behavior:**
The email of the applicant should be correctly set(e.g as path@test.com)

### **Root Cause:**
When the applicant signs the document, their email is explicitly set to `False` at [1]. This is done because the applicant is not linked to any user yet. Later, when generating the certificate, the system attempts to display the user's partner email at [2], which is `False`, causing the default fallback value (`john@example.com`) to be printed.

[1]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/hr_contract_salary/controllers/main.py#L53-L54

[2]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/sign/report/sign_log_reports.xml#L59

### **Fix:**
Use `signer_email` instead of the partner's email to ensure the correct email is displayed on the certificate every time.

**opw-6280170**

Forward-Port-Of: odoo/enterprise#123901
Forward-Port-Of: odoo/enterprise#123767

Issue:
The Item Trace Number according to CPA-005 standard should be a nonzero sequence that serves as unique reference ID for payments. Currently, Odoo sets the Item Trace Number of all payments as a zero-filled sequence 

According to CPA-005 standards on the Item Trace Number:
"The data elements (b), (c) and (d) each must be greater than zero or the TRANSACTION WILL BE REJECTED" (page 36).
https://www.payments.ca/sites/default/files/standard005eng.pdf

Steps to reproduce:
1. Install the module l10n_ca_payment_cpa005
2. Go into "CA Company"
3. In the configuration for "CA Company", add something to the fields "Short Name used in Canadian EFT" and "Company ID" i.e. "CCC"
4. Set all the fields in the "Canadian EFT/CPA Configuration" section of the bank journal
5. Set the bank record on the bank journal. Set the field "Financial Institution ID Number" field of the "Account Number" record of the bank journal to any numerical sequence
6. Create a bank account on "Azure Interior" and make sure to check the field to trust the bank account that you created (otherwise there will be an error)
7. Create two payments with the vendor of "Azure Interior" using the payment method of "Canadian EFT"
8. Create a batch payment for both payments created
9. Validate the batch payment and the export file should show up in the chatter
10. Note that in the export file, the Item Trace Number for each payment is set to be all zeros, whereas it should be a nonzero identification sequence

Solution:
Set the Item Trace Number to be the payment's id

opw-6323432

Forward-Port-Of: odoo/enterprise#123707
Forward-Port-Of: odoo/enterprise#123633

### Issue:
On Chilean export invoices, the customs information table may display data in the wrong columns

When `Origin Port` or `Destination Port` is not set, the corresponding `td` is omitted by QWeb, causing the remaining columns to shift left

This results in `Qty of Packages` appearing under `Origin Port` or `Destination Port` in the printed document

### Cause:
`l10n_cl_port_origin_id` and `l10n_cl_port_destination_id` have no default value and are optional fields
`t-out` on a falsy value omits the `td` entirely in QWeb, breaking the column alignment

Adding `or ''` ensures an empty `td` is always rendered, preserving the table structure regardless of whether the fields are set

### Steps to reproduce:
- Install `l10n_cl_edi_exports` and switch to CL Company
- Create an Invoice (any customer, any line)
- In the gear menu, select Print > Invoice PDF copy (Chile)

Before the fix, `Qty of Packages` appears under `Origin Port` when neither port field is set

opw-6304670

Forward-Port-Of: odoo/enterprise#121923