Currently, an error occurs when generating the `IRAS Audit File` for 
a `Singapore` company

**Steps to reproduce:**
- Install the `l10n_sg_reports` and `accountant` modules (without demo data).
- Create a new company with Singapore as the `country` and set `UEN` and `GST No.`, 
  then switch to this company.
- Navigate to Accounting > Reporting > Singapore > IRAS Audit File.
- Fill in the required details and click `Generate`.

**Error:**
`TypeError: 'account.account' object is not callable`

**Root cause:**
After the refactoring in PR [1], the code at [2] mistakenly calls `browse()` 
without arguments and then attempts to call the returned recordset with 
`line_account_ids`. Since `browse()` already returns a recordset, this results 
in calling an `account.account` recordset as a `function`, causing an `error`.

**Fix:**
This commit prevents an error during IRAS Audit File generation by correcting 
the `browse()` call to pass `line_account_ids` directly as its argument.

[1]:
https://github.com/odoo/enterprise/pull/72675

[2]:
https://github.com/odoo/enterprise/blob/444f120fbd4e7158b83c609ededf1b2598fc990f/l10n_sg_reports/models/iras_audit_file.py#L210

opw-5877947

Forward-Port-Of: odoo/enterprise#106150

Currently, an error occurs when opening an `accounting report` when the 
evaluated data produces a `zero denominator` during formula computation.

**Steps to reproduce:**
- Install the `account_reports` module (without demo) and enable `developer mode`.
- Navigate to Accounting > Reporting > Deferred Revenue.
- Click the `gear icon` to open the report configuration.
- Click `Add a line` to create a new report line.
- Click `Add a line` to create a new expression with:
>- Computation Engine: `Aggregate Other Formulas`
>- Formula: `0/0`
- Save the new expression and report line.
- Try to reopen the `Deferred Revenue`.

**Error:**
`ZeroDivisionError: division by zero`

**Root Cause:**
After commit [1], at [2], expressions without the `ignore_zero_division` 
subformula are evaluated in the else condition, causing an error when 
the `denominator is zero`.

**Fix:**
This commit prevents errors caused by zero denominators during formula 
evaluation and improves the clarity of the resulting error messages.

[1]:
https://github.com/odoo/enterprise/commit/2ba548564bd0bb68c36a589ed67b43251b5f45d0

[2]:
https://github.com/odoo/enterprise/blob/7adab8bfdccf5f0e97eb2894e065b63ea8200d20/account_reports/models/account_report.py#L3540-L3547

opw-5475146

Forward-Port-Of: odoo/enterprise#103773

*= account_bank_statement_import_csv

An exception is currently triggered when a user attempts to import a bank
transaction file containing more than 80 transaction lines (see ref file [1]).

Steps to produce an error:
- Install `Accounting (accountant)` module
- Go to `Accounting` > Click on `Bank` > Click `Upload`
- Upload  ref file [1] and click `Test/Import` >>> Error occurs

Error: `psycopg2.errors.SerializationFailure: could not serialize access
due to concurrent update`

Error from 19.0: `InvalidSavepointSpecification : savepoint "ef05b579-df3f
-11f0-bc75-74563c5c983f" does not exist`

The issue occurs because, in `model.py` code line [2] creates a `savepoint`.
Before this `savepoint` is closed, code line [3] is triggered during the
creation of the bank statement line [4] and attempts to commit the
cursor using `self.env.cr.commit()`. Because a commit is executed while
the savepoint is still active, the system fails when trying to close the
previously created savepoint.

This commit fixes the issue by avoiding cursor commits during the import
process. The `import_file=True` flag is added to the context when
`_cron_try_auto_reconcile_statement_lines` is called from `execute_import`,
allowing the method to safely skip commit/rollback logic when
`import_file` is present in the context.

[1]: https://docs.google.com/spreadsheets/d/19hKnR8pGB27xkbEHgYYXIkBaPXV8RZZE/edit?usp=sharing&ouid=111844484867458262929&rtpof=true&sd=true
[2]: https://github.com/odoo/odoo/blob/11c469086cb4d08453a70cd7bd30d7391f635ae3/odoo/orm/models.py#L971-L973
[3]: https://github.com/odoo/enterprise/blob/2683b77cd6688877c308d0733bccfc5ad84530c1/account_accountant/models/account_bank_statement.py#L218
[4]: https://github.com/odoo/enterprise/blob/2683b77cd6688877c308d0733bccfc5ad84530c1/account_accountant/models/account_bank_statement.py#L1780

sentry-6974536471
opw-5359810

Forward-Port-Of: odoo/enterprise#106780
Forward-Port-Of: odoo/enterprise#102760

When creating a future appointment via the backend, the generated lead's activity deadline is incorrectly set to today instead of the appointment date.

### Steps to reproduce

- Install `appointment_crm`.
- Go to Appointments > Schedule > Staff Booking.
- Create a booking for a future date (e.g., next month) and add a customer.
- Confirm the booking.
- Open the newly created Opportunity.
- Check the "Next Activity" deadline.
- It is set to today's date instead of the appointment's date.

### Cause

The `calendar.event` model maintains two sets of fields for timing: `start`/`stop` (Datetime) and `start_date`/`stop_date` (Date). Standard logic dictates that `start_date` and `stop_date` are only populated for All Day events (`allday=True`). For regular time-specific events, these fields are computed as `False` to avoid ambiguity.

When an appointment is created, `appointment_crm` generates a linked CRM Lead and schedules an activity. The code responsible for scheduling this activity (`activity_schedule`) was explicitly passing `event.start_date` as the `date_deadline`.

Since standard backend appointments are time-specific (not all-day), `event.start_date` is `False`. The `activity_schedule` method defaults to the current date (Today) when it receives a falsy value for the deadline. Consequently, creating a future appointment resulted in an immediate deadline.

### Fix

Modify the lead creation logic to use the standard calendar helper `_get_activity_deadline_from_start`.


opw-5780578

Forward-Port-Of: odoo/enterprise#106770
Forward-Port-Of: odoo/enterprise#106162

Refactored the logic to generate the Kardex report based on `stock.valuation.layer`, for the following reasons:

1. **Landed costs**: These must be considered in the report. Odoo already creates valuation layers for landed costs, and the report must use the date when the landed cost was recorded, not the original stock move date.
2. **Price adjustments**: Product price adjustments generate valuation layers without stock moves. These layers are now included in the report.

Additional fixes and improvements:

- Correctly map columns 18 to 26 in Report 13.1:
  - 18–20: Incoming movements
  - 21–23: Outgoing movements
  - 24–26: Final balance
- Ensure `cost_in` and `cost_out` values are always positive. The sign now depends on the movement quantity, not the unit cost.
- Replace the product list with a dictionary to track accumulated quantities and values per product for accurate balance calculation.
- Extend test coverage to include cases where the report includes opening balances due to past transactions.
- **MRP movements**: MRP processes don’t generate pickings, but their stock moves are linked to operation types. The report now uses codes `19` for incoming and `27` for outgoing MRP-related movements.
- **Reversal of pickings**: Since Odoo copies the original picking and skips reassignment logic, we now override the reversal wizard to set the correct PE operation type:
  - `25` for incoming reversals
  - `24` for outgoing reversals
- Force operation type `99` for all `A1` lines, as required by the report.
- Ensure report dates are processed in the user's timezone for consistency with the layer view in Odoo.

Forward-Port-Of: odoo/enterprise#88592

Currently, an error occurs when opening an `accounting report` when the 
evaluated data produces a `zero denominator` during formula computation.

**Steps to reproduce:**
- Install the `account_reports` module (without demo) and enable `developer mode`.
- Navigate to Accounting > Reporting > Deferred Revenue.
- Click the `gear icon` to open the report configuration.
- Click `Add a line` to create a new report line.
- Click `Add a line` to create a new expression with:
>- Computation Engine: `Aggregate Other Formulas`
>- Formula: `0/0`
- Save the new expression and report line.
- Try to reopen the `Deferred Revenue`.

**Error:**
`ZeroDivisionError: division by zero`

**Root Cause:**
After commit [1], at [2], expressions without the `ignore_zero_division` 
subformula are evaluated in the else condition, causing an error when 
the `denominator is zero`.

**Fix:**
This commit prevents errors caused by zero denominators during formula 
evaluation and improves the clarity of the resulting error messages.

[1]:
https://github.com/odoo/enterprise/commit/2ba548564bd0bb68c36a589ed67b43251b5f45d0

[2]:
https://github.com/odoo/enterprise/blob/7adab8bfdccf5f0e97eb2894e065b63ea8200d20/account_reports/models/account_report.py#L3540-L3547

opw-5475146

Forward-Port-Of: odoo/enterprise#103773

When creating a future appointment via the backend, the generated lead's activity deadline is incorrectly set to today instead of the appointment date.

### Steps to reproduce

- Install `appointment_crm`.
- Go to Appointments > Schedule > Staff Booking.
- Create a booking for a future date (e.g., next month) and add a customer.
- Confirm the booking.
- Open the newly created Opportunity.
- Check the "Next Activity" deadline.
- It is set to today's date instead of the appointment's date.

### Cause

The `calendar.event` model maintains two sets of fields for timing: `start`/`stop` (Datetime) and `start_date`/`stop_date` (Date). Standard logic dictates that `start_date` and `stop_date` are only populated for All Day events (`allday=True`). For regular time-specific events, these fields are computed as `False` to avoid ambiguity.

When an appointment is created, `appointment_crm` generates a linked CRM Lead and schedules an activity. The code responsible for scheduling this activity (`activity_schedule`) was explicitly passing `event.start_date` as the `date_deadline`.

Since standard backend appointments are time-specific (not all-day), `event.start_date` is `False`. The `activity_schedule` method defaults to the current date (Today) when it receives a falsy value for the deadline. Consequently, creating a future appointment resulted in an immediate deadline.

### Fix

Modify the lead creation logic to use the standard calendar helper `_get_activity_deadline_from_start`.


opw-5780578

Forward-Port-Of: odoo/enterprise#106770
Forward-Port-Of: odoo/enterprise#106162

Refactored the logic to generate the Kardex report based on `stock.valuation.layer`, for the following reasons:

1. **Landed costs**: These must be considered in the report. Odoo already creates valuation layers for landed costs, and the report must use the date when the landed cost was recorded, not the original stock move date.
2. **Price adjustments**: Product price adjustments generate valuation layers without stock moves. These layers are now included in the report.

Additional fixes and improvements:

- Correctly map columns 18 to 26 in Report 13.1:
  - 18–20: Incoming movements
  - 21–23: Outgoing movements
  - 24–26: Final balance
- Ensure `cost_in` and `cost_out` values are always positive. The sign now depends on the movement quantity, not the unit cost.
- Replace the product list with a dictionary to track accumulated quantities and values per product for accurate balance calculation.
- Extend test coverage to include cases where the report includes opening balances due to past transactions.
- **MRP movements**: MRP processes don’t generate pickings, but their stock moves are linked to operation types. The report now uses codes `19` for incoming and `27` for outgoing MRP-related movements.
- **Reversal of pickings**: Since Odoo copies the original picking and skips reassignment logic, we now override the reversal wizard to set the correct PE operation type:
  - `25` for incoming reversals
  - `24` for outgoing reversals
- Force operation type `99` for all `A1` lines, as required by the report.
- Ensure report dates are processed in the user's timezone for consistency with the layer view in Odoo.

Forward-Port-Of: odoo/enterprise#88592

Currently, an error occurs when opening an `accounting report` when the 
evaluated data produces a `zero denominator` during formula computation.

**Steps to reproduce:**
- Install the `account_reports` module (without demo) and enable `developer mode`.
- Navigate to Accounting > Reporting > Deferred Revenue.
- Click the `gear icon` to open the report configuration.
- Click `Add a line` to create a new report line.
- Click `Add a line` to create a new expression with:
>- Computation Engine: `Aggregate Other Formulas`
>- Formula: `0/0`
- Save the new expression and report line.
- Try to reopen the `Deferred Revenue`.

**Error:**
`ZeroDivisionError: division by zero`

**Root Cause:**
After commit [1], at [2], expressions without the `ignore_zero_division` 
subformula are evaluated in the else condition, causing an error when 
the `denominator is zero`.

**Fix:**
This commit prevents errors caused by zero denominators during formula 
evaluation and improves the clarity of the resulting error messages.

[1]:
https://github.com/odoo/enterprise/commit/2ba548564bd0bb68c36a589ed67b43251b5f45d0

[2]:
https://github.com/odoo/enterprise/blob/7adab8bfdccf5f0e97eb2894e065b63ea8200d20/account_reports/models/account_report.py#L3540-L3547

opw-5475146

Forward-Port-Of: odoo/enterprise#103773

When creating a future appointment via the backend, the generated lead's activity deadline is incorrectly set to today instead of the appointment date.

### Steps to reproduce

- Install `appointment_crm`.
- Go to Appointments > Schedule > Staff Booking.
- Create a booking for a future date (e.g., next month) and add a customer.
- Confirm the booking.
- Open the newly created Opportunity.
- Check the "Next Activity" deadline.
- It is set to today's date instead of the appointment's date.

### Cause

The `calendar.event` model maintains two sets of fields for timing: `start`/`stop` (Datetime) and `start_date`/`stop_date` (Date). Standard logic dictates that `start_date` and `stop_date` are only populated for All Day events (`allday=True`). For regular time-specific events, these fields are computed as `False` to avoid ambiguity.

When an appointment is created, `appointment_crm` generates a linked CRM Lead and schedules an activity. The code responsible for scheduling this activity (`activity_schedule`) was explicitly passing `event.start_date` as the `date_deadline`.

Since standard backend appointments are time-specific (not all-day), `event.start_date` is `False`. The `activity_schedule` method defaults to the current date (Today) when it receives a falsy value for the deadline. Consequently, creating a future appointment resulted in an immediate deadline.

### Fix

Modify the lead creation logic to use the standard calendar helper `_get_activity_deadline_from_start`.


opw-5780578

Forward-Port-Of: odoo/enterprise#106162

Currently, an error occurs when opening an `accounting report` when the 
evaluated data produces a `zero denominator` during formula computation.

**Steps to reproduce:**
- Install the `account_reports` module (without demo) and enable `developer mode`.
- Navigate to Accounting > Reporting > Deferred Revenue.
- Click the `gear icon` to open the report configuration.
- Click `Add a line` to create a new report line.
- Click `Add a line` to create a new expression with:
>- Computation Engine: `Aggregate Other Formulas`
>- Formula: `0/0`
- Save the new expression and report line.
- Try to reopen the `Deferred Revenue`.

**Error:**
`ZeroDivisionError: division by zero`

**Root Cause:**
After commit [1], at [2], expressions without the `ignore_zero_division` 
subformula are evaluated in the else condition, causing an error when 
the `denominator is zero`.

**Fix:**
This commit prevents errors caused by zero denominators during formula 
evaluation and improves the clarity of the resulting error messages.

[1]:
https://github.com/odoo/enterprise/commit/2ba548564bd0bb68c36a589ed67b43251b5f45d0

[2]:
https://github.com/odoo/enterprise/blob/7adab8bfdccf5f0e97eb2894e065b63ea8200d20/account_reports/models/account_report.py#L3540-L3547

opw-5475146

Forward-Port-Of: odoo/enterprise#103773

When creating a future appointment via the backend, the generated lead's activity deadline is incorrectly set to today instead of the appointment date.

### Steps to reproduce

- Install `appointment_crm`.
- Go to Appointments > Schedule > Staff Booking.
- Create a booking for a future date (e.g., next month) and add a customer.
- Confirm the booking.
- Open the newly created Opportunity.
- Check the "Next Activity" deadline.
- It is set to today's date instead of the appointment's date.

### Cause

The `calendar.event` model maintains two sets of fields for timing: `start`/`stop` (Datetime) and `start_date`/`stop_date` (Date). Standard logic dictates that `start_date` and `stop_date` are only populated for All Day events (`allday=True`). For regular time-specific events, these fields are computed as `False` to avoid ambiguity.

When an appointment is created, `appointment_crm` generates a linked CRM Lead and schedules an activity. The code responsible for scheduling this activity (`activity_schedule`) was explicitly passing `event.start_date` as the `date_deadline`.

Since standard backend appointments are time-specific (not all-day), `event.start_date` is `False`. The `activity_schedule` method defaults to the current date (Today) when it receives a falsy value for the deadline. Consequently, creating a future appointment resulted in an immediate deadline.

### Fix

Modify the lead creation logic to use the standard calendar helper `_get_activity_deadline_from_start`.


opw-5780578

Forward-Port-Of: odoo/enterprise#106162

Currently, an error occurs when generating the `IRAS Audit File` for 
a `Singapore` company

**Steps to reproduce:**
- Install the `l10n_sg_reports` and `accountant` modules (without demo data).
- Create a new company with Singapore as the `country` and set `UEN` and `GST No.`, 
  then switch to this company.
- Navigate to Accounting > Reporting > Singapore > IRAS Audit File.
- Fill in the required details and click `Generate`.

**Error:**
`TypeError: 'account.account' object is not callable`

**Root cause:**
After the refactoring in PR [1], the code at [2] mistakenly calls `browse()` 
without arguments and then attempts to call the returned recordset with 
`line_account_ids`. Since `browse()` already returns a recordset, this results 
in calling an `account.account` recordset as a `function`, causing an `error`.

**Fix:**
This commit prevents an error during IRAS Audit File generation by correcting 
the `browse()` call to pass `line_account_ids` directly as its argument.

[1]:
https://github.com/odoo/enterprise/pull/72675

[2]:
https://github.com/odoo/enterprise/blob/444f120fbd4e7158b83c609ededf1b2598fc990f/l10n_sg_reports/models/iras_audit_file.py#L210

opw-5877947

Forward-Port-Of: odoo/enterprise#106150

Currently, an error occurs when opening an `accounting report` when the 
evaluated data produces a `zero denominator` during formula computation.

**Steps to reproduce:**
- Install the `account_reports` module (without demo) and enable `developer mode`.
- Navigate to Accounting > Reporting > Deferred Revenue.
- Click the `gear icon` to open the report configuration.
- Click `Add a line` to create a new report line.
- Click `Add a line` to create a new expression with:
>- Computation Engine: `Aggregate Other Formulas`
>- Formula: `0/0`
- Save the new expression and report line.
- Try to reopen the `Deferred Revenue`.

**Error:**
`ZeroDivisionError: division by zero`

**Root Cause:**
After commit [1], at [2], expressions without the `ignore_zero_division` 
subformula are evaluated in the else condition, causing an error when 
the `denominator is zero`.

**Fix:**
This commit prevents errors caused by zero denominators during formula 
evaluation and improves the clarity of the resulting error messages.

[1]:
https://github.com/odoo/enterprise/commit/2ba548564bd0bb68c36a589ed67b43251b5f45d0

[2]:
https://github.com/odoo/enterprise/blob/7adab8bfdccf5f0e97eb2894e065b63ea8200d20/account_reports/models/account_report.py#L3540-L3547

opw-5475146

Forward-Port-Of: odoo/enterprise#106797
Forward-Port-Of: odoo/enterprise#103773

When creating a future appointment via the backend, the generated lead's activity deadline is incorrectly set to today instead of the appointment date.

### Steps to reproduce

- Install `appointment_crm`.
- Go to Appointments > Schedule > Staff Booking.
- Create a booking for a future date (e.g., next month) and add a customer.
- Confirm the booking.
- Open the newly created Opportunity.
- Check the "Next Activity" deadline.
- It is set to today's date instead of the appointment's date.

### Cause

The `calendar.event` model maintains two sets of fields for timing: `start`/`stop` (Datetime) and `start_date`/`stop_date` (Date). Standard logic dictates that `start_date` and `stop_date` are only populated for All Day events (`allday=True`). For regular time-specific events, these fields are computed as `False` to avoid ambiguity.

When an appointment is created, `appointment_crm` generates a linked CRM Lead and schedules an activity. The code responsible for scheduling this activity (`activity_schedule`) was explicitly passing `event.start_date` as the `date_deadline`.

Since standard backend appointments are time-specific (not all-day), `event.start_date` is `False`. The `activity_schedule` method defaults to the current date (Today) when it receives a falsy value for the deadline. Consequently, creating a future appointment resulted in an immediate deadline.

### Fix

Modify the lead creation logic to use the standard calendar helper `_get_activity_deadline_from_start`.


opw-5780578

Forward-Port-Of: odoo/enterprise#106770
Forward-Port-Of: odoo/enterprise#106162

**Issue**
Users without 'Admin' Sign rights could in some cases not access the sample template.

**Steps to reproduce**
1. Go to 'Templates' and archive the existing one in order to have the 'Try our sample document' shown and click on it.
2. Add some sign items to the template, and send it for a signature request.
3. With an user having only 'User: Own Templates' Sign rights, go to 'Templates' and click 'Try our sample document'.

Access Error:
Blame the following rules:
- sign.item: group_sign_user: Create and manage template items

**Cause**
When the template has an associated sign request, it is copied.
The problem is that the user currently doesn't have enough rights
to create sign items for the copied template:
https://github.com/odoo/enterprise/blob/2e8fb2ca274a0cf15d7b78a663bffe9cbb700153/sign/security/security.xml#L92-L101

**Change**
Change the `user_id` of the new template to allow creating the
sign items for it. The user also needs write access to the roles
of the sign items. Also make sure to properly remove the sign
items from the new template.

opw-5254566

Forward-Port-Of: odoo/enterprise#105558
Forward-Port-Of: odoo/enterprise#102227

*= account_bank_statement_import_csv

An exception is currently triggered when a user attempts to import a bank
transaction file containing more than 80 transaction lines (see ref file [1]).

Steps to produce an error:
- Install `Accounting (accountant)` module
- Go to `Accounting` > Click on `Bank` > Click `Upload`
- Upload  ref file [1] and click `Test/Import` >>> Error occurs

Error: `psycopg2.errors.SerializationFailure: could not serialize access
due to concurrent update`

Error from 19.0: `InvalidSavepointSpecification : savepoint "ef05b579-df3f
-11f0-bc75-74563c5c983f" does not exist`

The issue occurs because, in `model.py` code line [2] creates a `savepoint`.
Before this `savepoint` is closed, code line [3] is triggered during the
creation of the bank statement line [4] and attempts to commit the
cursor using `self.env.cr.commit()`. Because a commit is executed while
the savepoint is still active, the system fails when trying to close the
previously created savepoint.

This commit fixes the issue by avoiding cursor commits during the import
process. The `import_file=True` flag is added to the context when
`_cron_try_auto_reconcile_statement_lines` is called from `execute_import`,
allowing the method to safely skip commit/rollback logic when
`import_file` is present in the context.

[1]: https://docs.google.com/spreadsheets/d/19hKnR8pGB27xkbEHgYYXIkBaPXV8RZZE/edit?usp=sharing&ouid=111844484867458262929&rtpof=true&sd=true
[2]: https://github.com/odoo/odoo/blob/11c469086cb4d08453a70cd7bd30d7391f635ae3/odoo/orm/models.py#L971-L973
[3]: https://github.com/odoo/enterprise/blob/2683b77cd6688877c308d0733bccfc5ad84530c1/account_accountant/models/account_bank_statement.py#L218
[4]: https://github.com/odoo/enterprise/blob/2683b77cd6688877c308d0733bccfc5ad84530c1/account_accountant/models/account_bank_statement.py#L1780

sentry-6974536471
opw-5359810

Forward-Port-Of: odoo/enterprise#102760

Currently, an error occurs when opening an `accounting report` when the 
evaluated data produces a `zero denominator` during formula computation.

**Steps to reproduce:**
- Install the `account_reports` module (without demo) and enable `developer mode`.
- Navigate to Accounting > Reporting > Deferred Revenue.
- Click the `gear icon` to open the report configuration.
- Click `Add a line` to create a new report line.
- Click `Add a line` to create a new expression with:
>- Computation Engine: `Aggregate Other Formulas`
>- Formula: `0/0`
- Save the new expression and report line.
- Try to reopen the `Deferred Revenue`.

**Error:**
`ZeroDivisionError: division by zero`

**Root Cause:**
After commit [1], at [2], expressions without the `ignore_zero_division` 
subformula are evaluated in the else condition, causing an error when 
the `denominator is zero`.

**Fix:**
This commit prevents errors caused by zero denominators during formula 
evaluation and improves the clarity of the resulting error messages.

[1]:
https://github.com/odoo/enterprise/commit/2ba548564bd0bb68c36a589ed67b43251b5f45d0

[2]:
https://github.com/odoo/enterprise/blob/7adab8bfdccf5f0e97eb2894e065b63ea8200d20/account_reports/models/account_report.py#L3540-L3547

opw-5475146

Forward-Port-Of: odoo/enterprise#103773

Currently, an error occurs when generating the `IRAS Audit File` for 
a `Singapore` company

**Steps to reproduce:**
- Install the `l10n_sg_reports` and `accountant` modules (without demo data).
- Create a new company with Singapore as the `country` and set `UEN` and `GST No.`, 
  then switch to this company.
- Navigate to Accounting > Reporting > Singapore > IRAS Audit File.
- Fill in the required details and click `Generate`.

**Error:**
`TypeError: 'account.account' object is not callable`

**Root cause:**
After the refactoring in PR [1], the code at [2] mistakenly calls `browse()` 
without arguments and then attempts to call the returned recordset with 
`line_account_ids`. Since `browse()` already returns a recordset, this results 
in calling an `account.account` recordset as a `function`, causing an `error`.

**Fix:**
This commit prevents an error during IRAS Audit File generation by correcting 
the `browse()` call to pass `line_account_ids` directly as its argument.

[1]:
https://github.com/odoo/enterprise/pull/72675

[2]:
https://github.com/odoo/enterprise/blob/444f120fbd4e7158b83c609ededf1b2598fc990f/l10n_sg_reports/models/iras_audit_file.py#L210

opw-5877947

Forward-Port-Of: odoo/enterprise#106150

When creating a future appointment via the backend, the generated lead's activity deadline is incorrectly set to today instead of the appointment date.

### Steps to reproduce

- Install `appointment_crm`.
- Go to Appointments > Schedule > Staff Booking.
- Create a booking for a future date (e.g., next month) and add a customer.
- Confirm the booking.
- Open the newly created Opportunity.
- Check the "Next Activity" deadline.
- It is set to today's date instead of the appointment's date.

### Cause

The `calendar.event` model maintains two sets of fields for timing: `start`/`stop` (Datetime) and `start_date`/`stop_date` (Date). Standard logic dictates that `start_date` and `stop_date` are only populated for All Day events (`allday=True`). For regular time-specific events, these fields are computed as `False` to avoid ambiguity.

When an appointment is created, `appointment_crm` generates a linked CRM Lead and schedules an activity. The code responsible for scheduling this activity (`activity_schedule`) was explicitly passing `event.start_date` as the `date_deadline`.

Since standard backend appointments are time-specific (not all-day), `event.start_date` is `False`. The `activity_schedule` method defaults to the current date (Today) when it receives a falsy value for the deadline. Consequently, creating a future appointment resulted in an immediate deadline.

### Fix

Modify the lead creation logic to use the standard calendar helper `_get_activity_deadline_from_start`.


opw-5780578

Forward-Port-Of: odoo/enterprise#106770
Forward-Port-Of: odoo/enterprise#106162

Description of the issue/feature this PR addresses:
In a multi-company environment, confirming a Purchase Agreement (Blanket Order) automatically generates Vendor Pricelist (product.supplierinfo) entries for the linked
products. Currently, these entries default to the user's current active company rather than the company specified on the Purchase Agreement. This leads to data
inconsistency where pricelists are visible and owned by the wrong company.

Current behavior before PR:
When a Blanket Order belonging to Company A is confirmed by a user who has Company B as their current active company, the resulting Vendor Pricelist record is
assigned to Company B. This is because the company_id is not explicitly passed during the creation of the product.supplierinfo record, causing it to fall back to the
environment default.

Desired behavior after PR is merged:
The Vendor Pricelist record will explicitly use the company_id from the Purchase Agreement it originated from. This ensures that the pricelist is correctly assigned
to the agreement's company rather than from the active company

related to ticket i made 5909892