Hi,

When we purchase 'bienes de inversión' with ISP (Inversión de sujetos pasivo) the base and tax amounts must be declared in 303 in two gaps different of current National ISP, that it fits only 'bienes corrientes and servicios corrientes'. In addition, we have to mark the invoice as 'BienInversion' to SII, like @jco-odoo said here https://github.com/OCA/l10n-spain/issues/1793, but it will be the next PR.

Please @pedrobaeza @acysos @rafaelbn @HaraldPanten @AlbertCabedo  etc. check this

Paste AEAT answer about this question:
En cuanto al Modelo 303, una factura recibida correspondiente a un bien de inversión debe con Inversión del Sujeto Pasivo debe declararse tanto en las casillas 12 y 13 del IVA devengado como en las casillas 30 y 31 del IVA deducible (siempre que la adquisición o construcción, en su caso, de dicho bien de inversión se encuentre afecto a la actividad empresarial o profesional y se cumplan el resto de requisitos de deducción de las cuotas de IVA establecidos en los artículos 94 y siguientes de la Ley de IVA).

Regards

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

Forward-Port-Of: odoo/odoo#101918
Forward-Port-Of: odoo/odoo#98021

## Task Description

In some case, when trying to display the context menu on a pivot cell (doesn't seem to impact PIVOT.HEADER), we get a traceback caused by the arguments of the formula take into account in the `getFiltersMatchingPivot`, called by the `isVisible` property evaluation of the `set as filter` action.
These errors only rise when using a pivot with `__count` as measure and a positional argument.

## Reproducibility
This can be reproduced with the following steps:
1. Go to the CRM app
2. Create a pivot view
3. Group the row by Country
4. "Ungroup" the columns (keep only the total)
5. Set "__count" as measure
6. Insert the pivot on a new spreadsheet
7. Edit the pivot formulas to use positional argument for country_id
8. Insert a new filter on the country field
9. Right click on a pivot cell

## Fix Description
This issue is coming from the fact we try to get the value related to a field in the pivot formula using the 2nd and 3rd argument instead of using the last two arguments of the formula. This is fixed by passing to `getPivotHeaderValue` only the last two arguments of the pivot formula.

## Related Task/PR
- task-[2999181](https://www.odoo.com/web#cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form&id=2999181)
- https://github.com/odoo/enterprise/pull/32151




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

Forward-Port-Of: odoo/odoo#101381

Two commits

**[IMP] mrp_subcontracting: add some tests**

Tests for
- https://github.com/odoo/odoo/commit/e6a1e240f18bbc95475cd82154bb91a455704b15
- https://github.com/odoo/odoo/commit/fd22fe221026e353aac7414348b029ae7e290b2f

**[FIX] purchase_stock, mrp_subcontracting_dropshipping: dropship to subcontract**

A user can not buy a subcontracted product and directly deliver it
(dropship) to another subcontractor. Moreover, in such situation, the
received quantity is not correctly computed.

To reproduce the issue:
(Enable debug mode)
1. In Settings, enable "Storage Locations"
2. Create three products:
    - P1:
        - Storable
        - With a vendor V1
    - P2:
        - Storable
        - With a vendor V2
    - P3:
        - Consumable
3. Edit V1:
    - Customer Location: Physical Locations/Subcontracting Location
4. Create two BoMs:
    - Product: P1
        - Type: Subcontracting
        - Subcontractors: V1
        - Components: 1 x P2
    - Product: P2
        - Type: Subcontracting
        - Subcontractors: V2
        - Components: 1 x P3
5. Create a PO:
    - Vendor: V2
    - Deliver To: Dropship
    - Drop Ship Address: V1
    - Products: 1 x P2
6. Confirm the PO

Error: a Validation Error is raised at `mrp.production` creation because
of a missing field (`picking_type_id`).

In some cases, when getting the values to create the MO, the basic
`_prepare_subcontract_mo_vals` does not return any `picking_type_id`.
That's the reason why an override has been added in
`/mrp_subcontracting_dropshipping` (see [1] for more details). Thanks to
this override, if the usage of the destination location is `customer`,
we know that we are in a "dropship" situation and we manually define the
`picking_type_id`:
https://github.com/odoo/odoo/blob/d73e70f22e47e81e59aff0c9f578aff260447256/addons/mrp_subcontracting_dropshipping/models/stock_picking.py#L15-L17
However, in the above case, the subcontracted stock move starts from a
subcontracted location and also goes to a subcontracted location
(because of step 3). As a result, the if-condition is not respected and
the `picking_type_id` is not defined.

Once this issue is solved, there is a second one: suppose the PO
confirmed. The user validates the transfer. New error: the received
quantity on the PO is not updated. This is because of an incorrect
condition in `/purchase_stock._compute_qty_received`:
https://github.com/odoo/odoo/blob/d0537e32e5aa4b0fe2ad674ab3ec7c42ae1a12f9/addons/purchase_stock/models/purchase.py#L306-L315
Added by [2] and modified by [3], this condition checks that:
- the destination location usage is `internal` (correct, this is a
subcontracting location)
- the source location usage is not `supplier` (correct, this is a
subcontracting location, so it is `internal`)
- the destination location is not part of the warehouse children (here
is the issue: the SM does not have any warehouse, so it gives a false
positive)

So, because of the incorrect third condition, the whole condition is
respected. And because `to_refund` is `False` (which is correct), we
don't do anything. That's the reason why the received quantity is not
updated.

[1] https://github.com/odoo/odoo/commit/d73e70f22e47e81e59aff0c9f578aff260447256
[2] https://github.com/odoo/odoo/commit/e6a1e240f18bbc95475cd82154bb91a455704b15
[3] https://github.com/odoo/odoo/commit/fd22fe221026e353aac7414348b029ae7e290b2f

OPW-2922546

Forward-Port-Of: odoo/odoo#102133
Forward-Port-Of: odoo/odoo#100565

Description of the issue/feature this PR addresses:

How to reproduce the problem:
- Install the purchase_requistion, purchase_requistion_stock, and any Localization modules such as l10n_be or l10n_in
  (apart from USD currency any localization module)
- Error caught only when at the time of module installation but it must have a different currency_id apart from USD

https://watch.screencastify.com/v/1C7GQKHBASyiluGGkFfV

Cause of the problem:

Static values Currency USD cause the problem.
The following module will set the currency value to:

-  `l10n_be` - `EUR`
- `l10n_in` - `INR`
- `l10n_br` - `BRL`
 when we installed the following modules then `cls.env.user.company_id.currency_id` values get changes accordingly

  will lead to this error while the test cases for `purchase_requisition` will run
```
  Traceback (most recent call last):
  File /home/odoo/src/odoo/addons/purchase_requisition/tests/common.py, line 70, in setUpClass
    cls.env.user.company_id.currency_id = cls.env.ref(base.USD).id
  File /home/odoo/src/odoo/odoo/fields.py, line 1217, in __set__
    records.write({self.name: write_value})
  File /home/odoo/src/odoo/addons/account/models/company.py, line 301, in write
    raise UserError(_('You cannot change the currency of the company since some journal items already exist'))
  odoo.exceptions.UserError: You cannot change the currency of the company since some journal items already exist
```
Current behavior before PR:

- Standard test cases failed of the `purchase_requisition` module  while installing any localization module such as `l10n_be`, `l10n_in`

Desired behavior after PR is merged:
- standard test case of the `purchase_requisition` module get resolve



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

Forward-Port-Of: odoo/odoo#98174

pivot, graph, cohort views do not care to know whether a field
is readonly or required, as you cannot edit records in these views.

Even kanban is readonly in most cases:
- you can drag and drop records from one column to another,
  which is prevented if the group by field is readonly
  but this shouldn't rely on the fact the field is
  within the architecture, as you can group by on any fields
  from the search views / control panel.
  Hence, this shouldn't rely entirely on the modifiers passed on the field
  nodes in the view architecture alone.
- you can create new record inside the kanban,
  with a simplified form, thanks to the `quick_create`,
  but this uses an independant form view, in which the readonly and
  required modifiers are correctly passed.
So, `modifiers="{'readonly': true, 'required': true}"` can be dropped
for kanban views as well.

This allow to spare some KB by not setting useless modifiers in views.

e.g. CRM > My pipeline pivot

Before
```xml
<pivot string="Pipeline Analysis" sample="1">
    <field name="create_date" interval="month" type="row" modifiers="{&quot;readonly&quot;: true}"/>
    <field name="stage_id" type="col" on_change="1" can_create="true" can_write="true"/>
    <field name="expected_revenue" type="measure"/>
    <field name="color" modifiers="{&quot;invisible&quot;: true}"/>
    <field name="automated_probability" modifiers="{&quot;invisible&quot;: true, &quot;readonly&quot;: true}"/>
    <field name="message_bounce" modifiers="{&quot;invisible&quot;: true}"/>
    <field name="probability" on_change="1" modifiers="{&quot;invisible&quot;: true}"/>
</pivot>
```

After
```xml
<pivot string="Pipeline Analysis" sample="1">
    <field name="create_date" interval="month" type="row"/>
    <field name="stage_id" type="col" on_change="1"/>
    <field name="expected_revenue" type="measure"/>
    <field name="color" modifiers="{&quot;invisible&quot;: true}"/>
    <field name="automated_probability" modifiers="{&quot;invisible&quot;: true}"/>
    <field name="message_bounce" modifiers="{&quot;invisible&quot;: true}"/>
    <field name="probability" on_change="1" modifiers="{&quot;invisible&quot;: true}"/>
</pivot>
```

Regarding the change of behavior shown in `addons/web/static/tests/views/kanban_view_tests.js`.
It was introduced very recently, by myself, in
https://github.com/odoo/odoo/pull/100806
I revert this possibility to set readonly="0" on a field node in a
kanban view, because:
- First, this is not used anywhere in both odoo/odoo and
odoo/enterprise.
- Second, this really makes things harder if we want to do so:
  - as readonly="0" is passed, the "readonly" gets removed from the node
    modifiers, as they are simplified by removing falsy value:
    modifiers="{'invisible: True, 'readonly': False}" becomes modifiers="{'invisible': True}"
  - as readonly in not amongst the modifiers, it fallbacks on the model
    field property, in the javascript code, which is readonly: True.
  - the thing to do would be to still transfer "readonly"
    from the field attributes to the node modifiers.
    - which either mean to consider a kanban view as editable
      - this will cause issues because the validation mechanism
        will suddenly check the domain attribute property
        https://github.com/odoo/odoo/blob/d4a92b112d0554a2624f7768feb7d54e0484469f/odoo/addons/base/models/ir_ui_view.py#L1443
        and there will be plenty of views where some field used in the
        domains will be missing. Besides it is pointless to validate these
        domains as they are completely unused in kanban views
    - either mean to find another mechanism than "editable" to decide
      wheter to transfer the modifiers "readonly"/"required" or not,
      which over-complicates things.
    - besides only "readonly" would need to be passed, not "required.
So, to keep the code stupid simple, I remove this possibility added only
a few days ago, which is actually not used anywhere in standard for the
moment.

Forward-Port-Of: odoo/odoo#101924

If the decimal separator of the currently selected language is a comma,
exporting data in an xlsx would use a wrong float format

Steps to reproduce:
1. Install Invoicing
2. Go to Settings > Languages, add 'French / Français' language and
   switch to it
3. Go to Facturation > Fournisseurs > Factures
4. Export the data (there should be at least one amount with a decimal
   part)
5. The decimal part of the amounts is not displayed

Solution:
Always use the same decimal separator to print in the xlsx as we can
only use a dot as a decimal separator (the comma is used as the thousand
separator). The value will then be displayed to the user according to
his OS regional settings (see https://xlsxwriter.readthedocs.io/format.html#number-formats-in-different-locales)

Problem:
When using a comma for the float format, we actually specify the format
of the integral part of the number (the thousands) without displaying
the decimal part (which is represented with the dot)

opw-2965984

Forward-Port-Of: odoo/odoo#102188
Forward-Port-Of: odoo/odoo#99286

Customer display does not show the appropriate logo when multi-company is
enabled. The logo shown is always the logo of the default company.

Step to reproduce the issue:
1) Install Point of Sale and set up a second company
2) Put a logo on both companies (different ones)
3) Create a POS session on the newest company (not the default one)
4) In this session, activate Customer Display
5) Launch the session and open the Customer Display
The logo shown is the logo of the default company.

Solution: The issue is that when fetching the logo, we don't include
information about the current company. Thus, we include the logo of the default
company (at url /logo). We can easily specifiy which logo we need via the url
/logo?company={company_id}. As dynamic information cannot be included into a
CSS, we include this into the XML as it is done with other images rendered.
In our case, we don't need to retrieve the logo and map it to base 64 (for
ressources requiring to be logged in) because the logo is a resource available
to anyone.

opw-2745014

Forward-Port-Of: odoo/odoo#102136
Forward-Port-Of: odoo/odoo#93638

The followup rework didn't implement the case when a company would have no followup line defined. This would lead to tracebacks when trying to manually followup partners for such companies:
- when computing the followup status/line
- when setting a date for the next followup action

When joining invoices to a followup letter, every unpaid invoice would be attached, including those that are supposed to be blocked.

Some CSS changes broke the display of the followup wizard, rendering it unreadable.

This commit fixes those issues by:
- fixing the followup process when no followup lines are defined (allowing a similar flow, but with default values instead of the followup line's values)
- only including invoices that are not blocked when joining them to a followup letter
- fixing the followup wizard layout (mainly reworking the colspan for groups)

Quik note on the no followup line defined:
A company should be able to manually followup on customers even when they have not created any followup level (line). As for automatic followup, none will done as it requires the status of the customer to be 'in need of action', which it never is when there is no followup level created.
Regarding the default delay of 14 days and the setting of a next followup action date, this fix doesn't aim at changing that since it was how it was done before. However, after further discussion with CHKL and QDP, we will improve this later down the line as it seems a bit too arbitrary.

Part of the big task fixing bugs in accounting
Task id=2996493

Forward-Port-Of: odoo/enterprise#32163

## Task Description

In some case, when trying to display the context menu on a pivot cell (doesn't seem to impact PIVOT.HEADER), we get a traceback caused by the arguments of the formula take into account in the ´getFiltersMatchingPivot`, called by the "isVisible" property evaluation of the "set as filter" action.

These errors only rise when using a pivot with "__count" as measure and a positional argument.

Moreover, when trying to open the context menu with a filter defined without any field, we get another traceback.

## Reproducibility

The first issue  can be reproduced with the following steps:
1. Go to the CRM app
2. Create a pivot view
3. Group the row by Country
4. "Ungroup" the columns (keep only the total)
5. Set "__count" as measure
6. Insert the pivot on a new spreadsheet
7. Edit the pivot formulas to use positional argument for country_id
8. Insert a new filter on the country field
9. Right click on a pivot cell

The second issue can be reproduced with the following steps:
1. Open a spreadsheet with a pivot
2. Add a filter related to the pivot but without any field matching
3. Right-click on a pivot cell

## Fix Description

The first issue is coming from the fact we try to get the value related to a field in the pivot formula using the 2nd and 3rd argument instead of using the last two arguments of the formula. This is fixed by passing to getPivotHeaderValue only the last two arguments of the pivot formula.

For the second issue, we simply check that the pivot field is defined before looking at its name.

## Related Task/PR

task-2999181
https://github.com/odoo/odoo/pull/101381/

Forward-Port-Of: odoo/enterprise#32151