The Company Bike section in Belgian payroll fleet contract screens now aligns correctly on mobile devices. This makes the form easier to read and use for HR users working from smaller screens.

Follow-up of https://github.com/odoo/enterprise/pull/16345
and more specifically https://github.com/odoo/enterprise/commit/73eee9631ea6cd34c0ae0e7fbffab9b0aed867d1

Task-ID: 1929043

AFIP give us new resolution 4291 that request to print QR code in printed version of electronic invoices. For that we update the xml report footer and add some generic method to sanitze the identification number we are sending, the sanitize method is added here in order to be re used for other functionalities. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#67716 Forward-Port-Of: odoo/odoo#65033

AFIP give us new resolution 4291 that request to print QR code in printed version of electronic invoices. For that we update the xml report footer and add some generic method to sanitze the identification number we are sending, the sanitize method is added here in order to be re used for other functionalities.

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

Forward-Port-Of: odoo/odoo#67716
Forward-Port-Of: odoo/odoo#65033

Issue - Create a database with 2 users - Open the calendar application and create a meeting for you and the other user - In the option: set Privacy to 'Everyone' set Show times as 'Free' - Send the invitation to the other user Access Error (rule: Hide Private Meetings) Cause The 'calendar_event_global' ir.rule is deprecated and related ir.rules are now in calendar module (crm.meeting -> calendar.event). Solution Remove rule since deprecated. opw-2469433

Issue

	- Create a database with 2 users
	- Open the calendar application and create a meeting for you and the other user
	- In the option:
	  set Privacy to 'Everyone'
	  set Show times as 'Free'
	- Send the invitation to the other user

	Access Error (rule: Hide Private Meetings)

Cause

	The 'calendar_event_global' ir.rule is deprecated and related ir.rules
	are now in calendar module (crm.meeting -> calendar.event).

Solution

	Remove rule since deprecated.

opw-2469433

Forward-Port-Of: odoo/odoo#67681

Commit f6b019fcfdd35a693e8af43ae38d10e31e96284a aims to fix the rounding errors on AVCO valuated product when those exit stock. The issue was we fixed the value and the unit_cost as it is rounded in the curruncy precision. This is first wrong then useless. The wrong part : in case the stock is empty and we make an outgoing move, self.value = 0 so the unit_cost will be overridden to 0 while it should stay at the standard price. The useless part is that the unit_cost will be rerounded right

Commit f6b019fcfdd35a693e8af43ae38d10e31e96284a aims to fix the rounding
errors on AVCO valuated product when those exit stock. The issue was we
fixed the value and the unit_cost as it is rounded in the curruncy
precision. This is first wrong then useless.
The wrong part : in case the stock is empty and we make an outgoing
move, self.value = 0 so the unit_cost will be overridden to 0 while it
should stay at the standard price.
The useless part is that the unit_cost will be rerounded right after the
update to be written in database.

opw :

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#67590

When creating a journal entry in company C01, if user's sales team belongs to another company CXX, the default sales team of the journal entry is still the user's sales team. To reproduce the error: (Use demo data. Let C01 be the current company) 1. Add the `team_id` field to `account_move` form view: - With web_studio - Directly in the code: ```diff diff --git a/addons/sale/views/sale_views.xml b/addons/sale/views/sale_views.xml index 92cb2a72c4d..acc0e91e890 100644 --- a/

When creating a journal entry in company C01, if user's sales team
belongs to another company CXX, the default sales team of the journal
entry is still the user's sales team.

To reproduce the error:
(Use demo data. Let C01 be the current company)
1. Add the `team_id` field to `account_move` form view:
    - With web_studio
    - Directly in the code:
```diff
diff --git a/addons/sale/views/sale_views.xml
b/addons/sale/views/sale_views.xml
index 92cb2a72c4d..acc0e91e890 100644
--- a/addons/sale/views/sale_views.xml
+++ b/addons/sale/views/sale_views.xml
@@ -1154,6 +1154,17 @@
             </field>
         </record>

+        <record id="account_invoice_view_form" model="ir.ui.view">
+            <field name="name">account.move.form.inherit.sale</field>
+            <field name="model">account.move</field>
+            <field name="inherit_id" ref="account.view_move_form"/>
+            <field name="arch" type="xml">
+                <field name="ref" position="after">
+                    <field name="team_id" />
+                </field>
+            </field>
+        </record>
+
         <!-- Update account invoice !-->
         <record model="ir.ui.view" id="account_invoice_form">
             <field name="name">Account Invoice</field>
```
2. Create a second Company C02
3. Edit the Sales Team 'Europe':
    - Company: C02
4. Go to Accounting > Accounting > Journal Entries
5. Click on "Create"

Error: the default Sales Team is 'Europe'. However, this team belongs to
C02 and the user is creating a new JE in C01.

When creating a new journal entry, an `onchange` method uses the user's
sales team to define the JE's sales team.
However, the current user belongs to 'Europe', and the company of
'Europe' is now C02. Therefore, 'Europe' should not be used.

OPW-2375444

Forward-Port-Of: odoo/odoo#67470

Read commits for a description Forward-Port-Of: odoo/odoo#67253

Read commits for a description

Forward-Port-Of: odoo/odoo#67253

Current behavior before PR: When having a small screen, the composer in a chat window has no actual shortcut to send the message. Desired behavior after PR is merged: 'CTRL-Enter' keyboard shortcut will work for a non-mailing channel. LINKS: Task-2446076 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#65241

Current behavior before PR:
When having a small screen, the composer in a chat window has no actual
shortcut to send the message.

Desired behavior after PR is merged:
'CTRL-Enter' keyboard shortcut will work for a non-mailing channel.

LINKS:
Task-2446076

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

Forward-Port-Of: odoo/odoo#65241

[FIX] web: nested one2manys, onchange and no command Let's assume the following situation. We have a form view with a one2many field A displayed as a list. In the list, there is a one2many field B. B can't be edited, its value is computed by an onchange. By default, it contains a single record (i.e. the first value returned by the onchange is [[5], [0, 0, {...}]]). When another field (say C) changes, B's value is re-computed to [[5]]. Moreover, there is an onchange on A. In this form

[FIX] web: nested one2manys, onchange and no command

Let's assume the following situation. We have a form view with a
one2many field A displayed as a list. In the list, there is a
one2many field B. B can't be edited, its value is computed by
an onchange. By default, it contains a single record (i.e. the
first value returned by the onchange is [[5], [0, 0, {...}]]).
When another field (say C) changes, B's value is re-computed to
[[5]]. Moreover, there is an onchange on A.

In this form view, let's assume the following scenario. Create a
new record and add a line to A. In this new line, B already
contains a record. Change C. This triggers an onchange that
returns [[5]], and B is now empty. It triggers a second onchange,
on the main record (as field A changed).

Before this commit, in this second onchange, B's value wasn't sent
among the other values of the new line.

The spec says that for onchanges, we must send all data, not only
what has really changed. From that perspective, the above scenario
highlights an issue.

That issue had two root causes. First, commit [1] wrongly fixed
another issue, and as a consequence, when building what to send
for the onchange, we didn't generate the values for fields that
hadn't changed inside an x2many (for added subrecords at least).
This commit reverts the fix of [1], and fixes it differently by
only sending a command 1 (update) after a command 4 (link to)
when the record is dirty (i.e. when it has been modified). See
[1] for context and details.

Second, the code that generates the values to send to onchanges is
the same as the one that generates the values to save records
(write or create). However, when saving, we only send what has
really changed. The values are at some point processed to remove
empty command lists from the list of changes (as it means that
nothing changed). However, here we ignored the flag that stated
whether we want all field values or just what has changed. This
commit takes the flag into account before removing the field's
value.

[1] 3e3a244

Issue reported in task~2352524
  Model: account.move
  One2Many (A): account.move.lines
  Nested computed One2Many (B): tax_detail_ids
  Field triggering the onchange (C): tax_ids

Co-authored-by: Géry Debongnie <ged@odoo.com>

Forward-Port-Of: odoo/odoo#67709
Forward-Port-Of: odoo/odoo#67679

when sale from a website then GST treatment is not set and order is confirmed so not able to change it after this commit, GST treatment is set when creating a sale order or invoice from RPC remove readonly in the sent state for Reseller and Journal When an order is created from a website then onchange is not called so we set a journal when order is created and set a value on the journal from the warehouse -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.

when sale from a website then GST treatment is not set and order is confirmed so not able to change it

after this commit, GST treatment is set when creating a sale order or invoice from RPC

remove readonly in the sent state for Reseller and Journal

When an order is created from a website then onchange is not called so we set a journal when order is created and set a value on the journal from the warehouse



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

Forward-Port-Of: odoo/odoo#67428

Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#67449 Forward-Port-Of: odoo/odoo#62055

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#67449
Forward-Port-Of: odoo/odoo#62055

These are throttled/debounced so the handlers are sometimes called after the component has been destroyed. opw-2451752 Forward-Port-Of: odoo/odoo#67723

These are throttled/debounced so the handlers are sometimes called after the
component has been destroyed.

opw-2451752

Forward-Port-Of: odoo/odoo#67723

The left css property computation wasn't usefull for ltr mode and even worse, it introduced a bug when a horizontal bar was present (as often on mobile). The entire width of the table was used to compute the offset even though we only saw part of it (scroll bar). It's why this left css property was too high. We can simply remove this logic as "right: 0" on .o_optional_columns already do the job for the ltr mode. Note that we still need to compute the left property for the rtl mode

The left css property computation wasn't usefull for ltr mode and
even worse, it introduced a bug when a horizontal bar was present
(as often on mobile).

The entire width of the table was used to compute the offset even
though we only saw part of it (scroll bar). It's why this left css
property was too high.

We can simply remove this logic as "right: 0" on .o_optional_columns
already do the job for the ltr mode.

Note that we still need to compute the left property for the rtl mode
to put the dropdown menu above the table. Otherwise it will be on his left!

Steps to reproduce:
- Go to Subscription
- Open an existing record
- Try to open subscription lines column dropdown
=> You need to scroll on the right to see it.

Related PR: https://github.com/odoo/odoo/pull/62472
Related Task ID: 1929043

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#67686

Issue: On DB with a lot of product (e.g. 50K) the MO form is very slow open/modify. It is due to the `_compute_allowed_product_ids` which will set the `allowed_product_ids` fields with all product ids possible (32K), then the `convert_to_record` will take a bunch of time to filter out no-active product. Fix: In your case, to avoid to send bunch of ids to the web framework and bypass the costly `convert_to_record`, we decided to simply (static) the domain of `product_id` (`mrp.producti

Issue:
On DB with a lot of product (e.g. 50K) the MO form is very slow
open/modify. It is due to the `_compute_allowed_product_ids` which
will set the `allowed_product_ids` fields with all product ids possible
(32K), then the `convert_to_record` will take a bunch of time to filter
out no-active product.

Fix:
In your case, to avoid to send bunch of ids to the web framework and
bypass the costly `convert_to_record`, we decided to simply (static) the
domain of `product_id` (`mrp.production`). The flow will be slightly
different (doesn't filter depending of `bom_id`) but still good and
maybe better (we can now modify the product without removing the
BoM/product in the MO form).
Remove `allowed_product_ids`.

opw-2475151

odoo/upgrade#2272

Forward-Port-Of: odoo/odoo#67696

Issue: - Activate "Analytic Tags" and "Analytic Accounting" Settings - Create an Analytic Tags and select "Analytic Distribution" - Create Product -> Product type: Storable product, Update Quantity as 100, Sales Price like 100 - Product category -> Costing Method: Average Cost (AVCO) Inventory Valuation: Automated - Create Analytic Defaults Rules -> select created Analytic Tags & Product. - Create a SO -> Confirm it -> Delivery -> Validate it then system give validation message message

Issue:
- Activate "Analytic Tags" and "Analytic Accounting" Settings
- Create an Analytic Tags and select "Analytic Distribution"
- Create Product -> Product type: Storable product, Update Quantity as
100, Sales Price like 100
- Product category -> Costing Method: Average Cost (AVCO)
Inventory Valuation: Automated
- Create Analytic Defaults Rules -> select created Analytic Tags
& Product.
- Create a SO -> Confirm it -> Delivery -> Validate it
then system give validation message message:
"The operation cannot be completed: another model requires the record
being deleted. If possible, archive it instead.
Model: Analytic Line (account.analytic.line),
Constraint: account_analytic_line_group_id_fkey”
But can be validated from the Inventory app.

Technical information:
It is due to the `default_group_id` in context put in
`action_view_delivery` method, it context key allows to create delivery
(tree view of `stock.picking`) with the correct `group_id`
("Procurement Group").
But the this name field is also used in the
`account.analytic.line` model. Moreover, the
the `_prepare_analytic_distribution_line` doesn't return any value for
`group_id` which means, that at the creation of the
`account.analytic.line` the `group_id` (id of `procurement.group`)
which will wrongly used.

Solution:
Because the `group_id` field on `account.analytic.line` is a related
store of `account_id.group_id`. We can set it directly in the
`_prepare_analytic_distribution_line` with the correct value.

opw-2442493

Forward-Port-Of: odoo/odoo#67183

Fine tuning of f816c326f348ff78a982f91a736cc005d3e0cd31 We should not look at the `seq` when grouping again. opw-[2472061](https://www.odoo.com/web#active_id=2472061&cids=1&id=2472061&model=project.task&menu_id=) -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#67481

Fine tuning of f816c326f348ff78a982f91a736cc005d3e0cd31
We should not look at the `seq` when grouping again.

opw-[2472061](https://www.odoo.com/web#active_id=2472061&cids=1&id=2472061&model=project.task&menu_id=)





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

Forward-Port-Of: odoo/odoo#67481

Description of the issue/feature this PR addresses: Documento di Trasporto feature Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#67476 Forward-Port-Of: odoo/odoo#65591

Description of the issue/feature this PR addresses:

Documento di Trasporto feature

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#67476
Forward-Port-Of: odoo/odoo#65591

This commit enables the users to export all the files required by AFIP for the new digital VAT book in a zip folder. fw-port of #15559 Forward-Port-Of: odoo/enterprise#17030

This commit enables the users to export all the files required by
AFIP for the new digital VAT book in a zip folder.

fw-port of #15559

Forward-Port-Of: odoo/enterprise#17030

task 458 --- Thanks to new changes in AFIP we need to sent information for invoice validation when the type of document is MiPyme. We add a new field that let the user to set this info and we update the logic of electronic invoice to sent this info when validating mipyme invoices in AFIP Forward-Port-Of: odoo/enterprise#17008 Forward-Port-Of: odoo/enterprise#16463

task 458
---
Thanks to new changes in AFIP we need to sent information for invoice validation when the type of document is MiPyme. We add a new field that let the user to set this info and we update the logic of electronic invoice to sent this info when validating mipyme invoices in AFIP

Forward-Port-Of: odoo/enterprise#17008
Forward-Port-Of: odoo/enterprise#16463

Issue ----- String formatting may fail if the string too format are translated poorly (ie: '%s with %s' become '% S ...') Solution -------- Use the more resiliant api _(text, params) than _(text) % params in case the translation is wrong Forward-Port-Of: odoo/enterprise#16933

Issue
-----
String formatting may fail if the string too format are translated
poorly (ie: '%s with %s' become '% S ...')

Solution
--------
Use the more resiliant api _(text, params) than _(text) % params
in case the translation is wrong

Forward-Port-Of: odoo/enterprise#16933

- Install sale_management, sale_intrastat - Do not install l10n_be_sale_intrastat - Create a Product and set its Country of Origin (in Accounting tab) - Create a SO with created Product - Create invoice "Product Country" of invoice line is not set. In previous version, "intrastat_product_origin_country_id" field was defined in l10n_be_intrastat module and the code setting it on invoice line was defined in bridge module l10n_be_sale_intrastat. But since 14.0, "intrastat_product_origin_

- Install sale_management, sale_intrastat
- Do not install l10n_be_sale_intrastat
- Create a Product and set its Country of Origin (in Accounting tab)
- Create a SO with created Product
- Create invoice
"Product Country" of invoice line is not set.

In previous version, "intrastat_product_origin_country_id" field was defined in
l10n_be_intrastat module and the code setting it on invoice line was defined in
bridge module l10n_be_sale_intrastat.
But since 14.0, "intrastat_product_origin_country_id" field has been moved to
account_intrastat module.
Therefore, the code setting product origin country to invoice line from SO line
can be moved to sale_intrastat module.

This commit makes l10n_be_sale_intrastat module useless.

opw-2454201

Forward-Port-Of: odoo/enterprise#17002