Use case: the eco-taxes (recupel, auvibel, etc) are fixed taxes in Odoo,
which apply before the "regular" (percentage) tax on an invoice line. We
can have one or more fixed taxes and 1 regular tax.

In EN16931, there can only be 1 tax per invoice line. Thus, the fixed
taxes are encoded as charge on the invoice lines (with reason code
`AEO`: "Collection and recycling"). The tags `AllowanceCharge` (in UBL)
and `SpecifiedTradeAllowanceCharge` (in CII) are used. Then a serie of
tax related infos need to be changed: the taxes in UBL/CII should not
contain the fixed ones and the total untaxed amount needs to be adapted,
as well as the total tax amount (since the fixed taxes were removed).

To be able to import the fixed taxes back in Odoo, the charges on the
invoice lines are read and their names and amounts are used to search on
the existing taxes.

task-3274208

closes odoo/odoo#122518

X-original-commit: 891f3a1a
Signed-off-by: Laurent Smet <las@odoo.com>

The missing 15A tax report line was added in odoo/odoo#90369 but it was not included in the VAT Payable/ Refundable Total line.
With this commit, we add codes to TotalA and TotalB and modify the final total to use these codes instead.

Bug report directly to me

closes odoo/odoo#122843

Signed-off-by: John Laterre (jol) <jol@odoo.com>

Steps to reproduce:
- install l10n_be (company B)
- stay on Company A and create a cash rounding
- Go to Company B and create an invoice
- In Other Infos > Cash Rouding Method, set it to the earlier created one
- Save

Issue:
You won't be able to save. But the message is too generic to know what is the cause of it
"Missing required account on accountable invoice line."

Cause:
The field `profit_account_id` is company_dependent. Therefore, the same cash rounding record will be accessible in both companies but in Company B the `profit_account_id` won't be set.
When Saving, we compute a cash difference (rounding) and try to create a new line for it. But since there is no account set, the sql constraint will be raised.

Solution:
The less dirty solution is to have an onchange that check that whenever we want to set a cash rounding method, it has all the required fields set

opw-3185950

closes odoo/odoo#120892

Signed-off-by: Josse Colpaert <jco@odoo.com>

Steps to reproduce:
- set up a header with company logo
- print 20 sale orders in arabic

Bug:
header disapears on most pages

Fix:
add a setting to allow users to increase the delay before printing

opw-3217155

closes odoo/odoo#122831

X-original-commit: 5d18944b
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

On this situation:
* P1 consumable product, kit, with components P2 and P3 in its BoM using
  1 of each
* P2 comsumable product, kit, with component P3 using 1 in the BoM
* P3 storable product, 10 units in stock

Before:
The qyt_available for P1 is 10. That's incorrect: to assemble one P1 we
need precisely two of P3s, one for P2 BoM then an extra for P1 BoM.

After:
The qyt_available for P1 is 5.

closes odoo/odoo#121660

X-original-commit: d02851d5
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

The test_current_leave_status checks the correct implementation of different
hr.leave computed fields. To do this, a leave is created, during the test. The
test fails however, when the employee is not supposed to work during the leave
period, which can happen when running the test on certain days. The test is
made deterministic again by adding the number_of_days field to the dict. As
this is a stored field, the created leave entry will be considered valid.

closes odoo/odoo#122826

X-original-commit: a1dffd3f
Signed-off-by: Kevin Baptiste <kba@odoo.com>

closes odoo/odoo#122546

X-original-commit: 3e757c59
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Usecase to reproduce:
- Set reservation method to closest location
- Set the POS as real time stock
- Put 1 unit in A and 1 unit in location B
- Create a SO for 1 unit
- Sell it in the POS

Expected behavior:
The unit has been taken from the reservation in location A

Current behavior:
The unit is taken from B

It happens because the SO is unreserved after the new picking
and stock.move.line creation. Since the unit is reserved, he
can't pick it and take a random ones.
The solution here is to unreserve the related stock.move to
free the reserved unit, it will not always be the same than the
SO but it will consider it in the removal strategy. It could
also fix the case where only 1 unit remains in stock and he won't
pick it.

opw-3271217

closes odoo/odoo#121695

Signed-off-by: Engels Robin (roen) <roen@odoo.com>

Current behavior:
When creating a credit note from a PoS order, the credit note is not
linked to the invoice of the orginal order.

Steps to reproduce:
- Make an order in the PoS, validate it and invoice it
- Make a refund of this order and invoice it too.
- Go to the credit note, the original invoice is not mentionned in the
  reference field.

opw-3150637

closes odoo/odoo#119952

Signed-off-by: Engels Robin (roen) <roen@odoo.com>

Steps to reprodue:
- Create a dropshipped product
- Sell the product to a client with a different language set
- Print the delivery slip

Bug:
delivery slip is currently being printed in the vendor's language

Fix:
Print the delivery slip in the client language when possible

opw-3193015

closes odoo/odoo#122706

X-original-commit: 832b4145
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

When moving a package, the quant at source location is not
automatically removed

To reproduce the issue:
1. In Settings, enable
   - Packages
   - Storage Locations
2. Create a storable product P
3. Update the on hand quantity
   - 1 x P at WH/Stock in package PK
4. Create a planned delivery D with 1 x P
5. Confirm and reserve D
   - PK should be reserved
6. Validate
7. Open the package
   - Its location is "Partner Locations/Customers", which make sense
8. Inventory > Configuration > ... > Locations, open WH/Stock
9. Current Stock

Error: There is a line with PK. The quantity is 0 but still, it
create some confusion for the user who could believe that the package
is still in WH/Stock

This issue does not occur if the user goes through the product form
and click on the on hand quantity. The "incorrect" quant will not be
there. This is because, when loading the action, we call
`_quant_tasks`:
https://github.com/odoo/odoo/blob/05a7f5c04804423cfc3a833a1b3f0b5eec3fc147/addons/stock/models/stock_quant.py#L296-L300
This method will clean the quants (merge & unlink)

However, in the above case (step 9), the action is defined on XML side:
https://github.com/odoo/odoo/blob/7d4dfeb0e26b387dee312897264a68963f90267f/addons/stock/views/stock_location_views.xml#L24-L26
https://github.com/odoo/odoo/blob/d956e719d43c68abe6210e3136db576aaa6f60b8/addons/stock/views/stock_quant_views.xml#L190-L196


So, we can't make it behave as it does from the product form,
unfortunatly.

As alternative, we can try to call `_unlink_zero_quants` when we are
moving a package (and not `_quant_tasks` for perf matters as, so far,
we will not have any quant to merge)

OPW-3292238

closes odoo/odoo#122673

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Steps to reproduce the bug:
- Drop the "Form" snippet on the website.
- Add a new field.
- Replace the field label by two quotation marks (`""`).
=> Traceback appears.

Since [1], it is possible for the user to create forms whose fields can
have a conditional visibility, meaning that the field is only visible if
another field in the form meets certain conditions. Due to that, there
is a mechanism that verifies if a condition on a field should be updated
when the user modifies the label of a field. To do so, a `querySelector`
is searching for an element that has a `data-visibility-dependency` set
to the previous field name by doing a querySelector of type
`querySelectorAll('.s_website_form_field[data-visibility-dependency="${previousInputName}"]')`.
Because `previousInputName` is set to `"`, it is not considered as a
character and an error is thrown.
To resolve this problem, strings that are stored in `name`, `data-name`
and `data-visibility-dependency` are encoded: All the occurrences of `"`
are replaced by `"`, all the occurrences of `'` are replaced by
`'` and all the occurrences of ``` ` ``` are replaced by `‘`.

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



opw-3246341

closes odoo/odoo#117632

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

The goal of this commit is to be able to use the `addCustomField`
function with a `type` argument that is different of `checkbox`,
`radio` or `select`.

opw-3246341

Part-of: odoo/odoo#117632

Group the res_partners in self by placeholder_path value before
calling __setitem__ on each group. Because placeholders are
independent from the recordset, we can set the value
of res_partner[avatar_field] to a placeholder for a recordset
of partners. When self contains lots of partners without
image_field value, this speeds up the _compute_avatar function
noticeably. This in turn speeds up stuff like loading
the Contacts KanbanView (search_read on res_partner).

Example speedup: In a database without any image for the partners,
search_read for avatar_128 with limit=80: 609ms -> 64ms.

opw-3128771

closes odoo/odoo#113756

Signed-off-by: Rémy Voet <ryv@odoo.com>

Before this commit, the widget value was updated (based on the current
state) prior to updating the snippet UI. As a result, the widget value
reflected used the non-updated UI labels.

task-3112890

closes odoo/odoo#122279

X-original-commit: b2daf688
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Divyesh Vyas (divy) <divy@odoo.com>

When processing several SMLs at once, the 'same product' policy of a
storage category is not respected

To reproduce the issue:
1. In Settings, enable:
   - Multi-Step Routes
   - Storage Categories
   - Packages
2. Create a Storage Category SC:
   - Allow New Product: same
3. Create two locations L1, L2:
   - Parent: WH/Stock
   - Type: Internal
   - Storage Category: SC
4. Create a putaway rule:
   - When in: WH/Stock
   - Package type: Pallet
   - Store to: WH/Stock
   - Having Category: SC
5. Edit the warehouse:
   - Incoming Shipments: 2 steps
6. Create two products P01, P02:
   - Type: Storable
7. Create a planned receipt R:
   - To: WH/Input
   - Operations:
     - 1 x P01
     - 1 x P02
8. Mark R as Todo
9. Create two packages:
   - 1 x P01 in PK01 (! PK01 must be a Pallet)
   - 1 x P02 in PK02 (! PK02 must be a Pallet)
10. Validate R
11. Open the related internal transfer

Error: Both packages are redirected to L1. Considering the product
policy of SC, one line should be redirected to L1 and the second one
to L2

To apply the product policy, the code looks at the quants of each
location. But it does not consider the incoming SMLs. Therefore, when
applying the putaway rule to the first SML, it selects L1 (which
makes sense). Then, for the second SML, because it does not see the
first one, it considers that L1 is empty and can be selected, hence
the error.

OPW-3204924

closes odoo/odoo#122616

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Steps to reproduce:

- Install industry_fsm_report, website
- Create Project P, add column/stage PC.
- Edit stage, Email Template = Task: Intervention Schduled.
- Edit the template > Advanced Settings > Optional report to print and
  attach = Worksheet Report (PDF). Save everything.
- Go to website, "contact us" page > Edit the form, Action = Create a
  task, Project = P > Save

Issue:

When you first submit the form, it will fail, but the task will be
created and visible in project P. By instinct, the user will submit the
form again, so the task will be duplicated. The second form submit will
return a success message.

When submitting a form, we first generate a savepoint (added in
commit [1]).
Since this is the first interaction with the report system, during the
handling of the form, the assetsbundle will be generated (see keyword
'commit_assetsbundle'), which will cause a commit.
Finally, assuming no other error is raised, we try to delete the
savepoint.
However, since a commit was executed, then the savepoint will no longer
exist, which will cause an error status to be returned.

Solution:

When submitting a form, pass `commit_assetsbundle=False` to the record
creation, which prevents the commit from happening.

This solution has a downside; creating the record also sends an email
and the report attached to that email will have broken styling. This is
still an improvement to the current behaviour, which doesn't send the
first email at all.

[1]: https://github.com/odoo-dev/odoo/commit/5a499ecf113f08c11d2b33b47680dd00ec1b297b



opw-3183912

closes odoo/odoo#122571

X-original-commit: a3249673
Signed-off-by: Romain Derie (rde) <rde@odoo.com>

A raw query is not necessary to produce the desired result, found
activities need to be kept only if the corresponding record can be found
with standard search (which includes multi-company check).

Part of task-3266643

closes odoo/odoo#122557

X-original-commit: 03c3d440
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

Failing use case: While having purchase_stock installed, create and confirm a request for quotation, received some products but no bill for it. Now select the PO is the list, click on 'Action > Accrued Expense Entry'. Make sure the wizard will effectively create an accrued expense entry (it should be the case if you have some product received and not billed).
Upon confirmation of the wizard, the system will recompute the received quantity on the original PO, logging notes that pollutes, confuses and spams its followers.

The reason is that we use a new record to compute the difference between the received and billed quantities at a given date in the past, and even if track_qty_received is called on a newid, it will find back the original PO where doing line.order_id.

The solution is to check in the context if we're in such use case before logging, because we know that calling the accrued expense entry wizard aims not to change the received quantity in any wase

closes odoo/odoo#122448

Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>

Steps to reproduce the bug (before the commits of this PR):
- Drop a Cover snippet on the website.
- Change the parallax to "None".
- Save and edit.
- Modify an option (for example, add a filter) to add the
`o_modified_image_to_save` class to the image.
- Change the parallax to "Fixed".
- Save.
- Inspect the Cover snippet.
=> The `span` element has the attributes `data-snippet="s_cover"` and
`data-name="Cover"`. Note that this could lead to problem during the
migration process.

Let's analyze the process  in order to better understand the problem:
- At the change of the parallax to "None", there is a change of the
target thanks to the call to `setTarget()`. The new target is now the
`section` element.
- At the save and edit, there is a call to `_loadImageInfo()`. All the
dataset (including `data-snippet` and `data-name`) of the new target is
copied in `this.img`.
- At the modify of an option, the `o_modified_image_to_save` class is
added to `this.img`.
- At the change of the parallax to "Fixed", there is a change of the
target thanks to the call to `setTarget()`. The new target is now the
`span` element.
- At the save, `cleanForSave()` is called and because there is the
`o_modified_image_to_save` on `this.img`, all the dataset of `this.img`
(including `data-snippet` and `data-name`) is copied on the new target
(the `span` element).

Note that this problem is resolved by the second commit of this PR.
Indeed, the dataset of the target is first filtered by
`_whiteListAttributes` before being copied into `this.img`. However,
databases that already have the problem will not be fixed by. The goal
of this commit is to remove the `data-snippet="s_cover"` and the
`data-name="Cover"` from the `span` elements in those existing
databases.

task-3287330

closes odoo/odoo#121682

X-original-commit: https://github.com/odoo/odoo/commit/9e48950e0c1268cfb2f5855861e7e95fd7a4abcd


Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: loco-odoo <loco@odoo.com>

*: web_editor, website

Steps to reproduce the bug:
- Add a Cover snippet on the website.
- Put a "Blur" filter on the background image.
- Save.
- Change the parallax from "Fixed" to "None".
- Save and edit.
=> The "Filter" option displays "None" but should display "Blur".

When changing the parallax, `setTarget()` is called. The goal of this
function is to transfer the `background-image` from the old target to
the new one. The commit modifies this function by adding the transfer of
the dataset information relative to the background image from the old
target to the new one. It also transfers the `o_modified_image_to_save`
class from the old target to the new one if needed.

task-3287330

X-original-commit: https://github.com/odoo/odoo/commit/c06f39e3b6b44ffb433e17a457bd719a52842fa0
Part-of: odoo/odoo#121682

For background images, modifying options such as "Filter" does not
directly lead to the modification of their corresponding data attributes
in the DOM as those modifications are done at the save request. This
should not be the case. The goal of this commit is to, as for regular
images, modify their corresponding DOM data attributes at the option
update.

Steps to reproduce the bug:
- Add a Cover snippet on the website.
- Replace the background image by one of your own.
- Add a filter to the background image.
- Inspect the Cover snippet.
=> The `data-gl-filter` attribute has not been added in the DOM and you
have to click on "Save" for it to be actually added.

task-3287330

X-original-commit: https://github.com/odoo/odoo/commit/597c9bb9fc9cff5c2276862faaa99c4546e29a90
Part-of: odoo/odoo#121682

Steps to reproduce the bug:
- Add a cover snippet on the website.
- Change the background image with one of your own.
- Save and edit again.
=> Options such as "Filter", "Width" and "Quality" do not appear
anymore.

The problem is that the `src` attribute of the background image is not
correctly updated when initializing the image. This is because the
target used to recover the URL of the background image is the snippet
and not the image itself. This problem is resolved by ensuring that the
argument of the function `getBgImageURL` is the background image. Now
that the `src` attribute is correctly updated, the `computeVisibility`
function of the the `BackgroundOptimize` option works properly and the
options "Filter", "Width" and "Quality" are displayed as wanted.

Note that now, the dataset of the target is filtered with a "white list"
(BACKGROUND_IMAGE_ATTRIBUTES) before being copied in the dataset of
`this.img`. Indeed, if the parallax is set to "None" for example, we do
not want data attributes such as `data-snippet` to be copied in the
dataset of `this.img`.

task-3287330

X-original-commit: https://github.com/odoo/odoo/commit/31ba9060723f365d16d51d3de0acf42c5e95f63b
Part-of: odoo/odoo#121682

Steps to reproduce:
In an account move, if the partner_id is changed to one that does not have a value assigned in the property_purchase_currency_id field and with a value in the context for default_currency_id,
when passing through the _onchange_partner_id function of the purchase module,

Cause:
the variable currency_id will take the value in the context as second option causing an error when trying to get the value in currency_id.id because currency_id will be an integer and not a record.

issue-121232

closes odoo/odoo#121921

X-original-commit: e04d4a0b
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>

Steps to reproduce:
1. Create a BoM for a product tracked by serial number
2. Create a Qualty Control point for that product
3. Create a MO with Quantity: 2 Units
4. Confirm the MO
5. Click on Mass Produce
6. Generate the 2 Serial Numbers and apply

Bug:
quality check not registered on the backorder

Fix:
adding a function to be overloaded in Entreprise
back port of this fix[1]

[1]:https://github.com/odoo/odoo/pull/95982



opw-3210242

closes odoo/odoo#121169

Related: odoo/enterprise#40951
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>

closes odoo/odoo#122442

X-original-commit: fa2cb330
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

Steps to reproduce the bug :

- Add the same google font twice with the font family selector in the
option tab of the editor panel.
- The font will be displayed only once in the font selector menu but 2
trash icons will be added, one for the added font and one for the font
that was already there.

This commit fix this and allows now the user to add the same font twice,
but only to replace a served font by a local font. The opposite does not
make sense, but if the user really wants to replace a local font with a
served, it is always possible by deleting the locale beforehand.

In addition, this commit adds a cloud icon next to the default fonts of
the theme. Since these fonts are served by Google, it is logical to have
the cloud icon. This is consistent with the cloud icon that is present
when the user adds a font served by Google.

task-2998689

closes odoo/odoo#122359

X-original-commit: be503205
Signed-off-by: Romain Derie (rde) <rde@odoo.com>

After commit 9bf54f09, we assumed that
the date field of a move was never empty. On the form view, it can be
(temporarily) empty though (before save), causing an error when trying
to read it.

We now don't try to recompute the name when the date is empty, thus
preventing the date field to be read in that method.

task-3326834

closes odoo/odoo#122297

X-original-commit: 5a3a8d0b
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>

The uom should be editable on new lines, independently of their state.
With this commit, users will be able to change the uom on new lines of locked/cancelled/confirmed orders.

closes odoo/odoo#122246

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

When creating an downpayment invoice for a SO with a incoterm different than the default one, this invoices ignores the incoterm you defined and uses the default value.

This issue is happening because in the _prepare_invoice_values is not passing the value of correct value of the incoterm and the default value is being used.

How to reproduce:
1. Active "incoterms" and choose a default incoterms in settings
2. Create a SO with a incoterm different than the default one
3. Create a downpayment invoice
4. In the new created invoice the incoterm is set as the default incoterm instead of the previously defined

closes odoo/odoo#120823

Opw: 3284556
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>

as Adyen sends the same notification data for POS and online payments
that can not be distiguished, the webhook controller logs a stacktrace
for every POS payment. If the payment_adyen is installed it generates
noise in logs as the POS transaction can not be found in online
payments. To clear the log we make missing transaction as warning to
not log the stacktrace.

task-2960381

closes odoo/odoo#120625

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Steps to reproduce:
Without being logged in,
complete the purchase flow on the ecommerce,
taking care to have a different billing
and shipping address.
If you change the delivery address,
you will get an access error.

Cause:
In some cases, we do not have access to
the `name` field of the `partner` record.

Solution:
Add `sudo` to be able to read the fields.

opw-3276877

closes odoo/odoo#122258

X-original-commit: 1d6ae6bb
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>

When user enters empty space in name field instead of entering an
actual name and confirm their billing, shipping address then when
they click on paynow to confirm order they will face the issue
'list index out of range'.

Note : Do the paypal configuration before following below steps.

Steps to produce:
1) Vist the website as a public user.
2) Create a sale order by adding some products to the cart.
3) While entering shipping and billing address, in the name field enter
some space.
4) Click on next button.
5) Now a sale order is created.
6) Go to orders through 'website' module.
7) Open the order created and generate a payment link.
8) Paste that payment link in another tab or browser .
9) Click on pay
10) By following above steps you will encounter the error.

This commit will prevent the above error.

sentry - 4177783431

closes odoo/odoo#122229

Signed-off-by: Saurabh Mishra (sami) <sami@odoo.com>

1.

Infinite loop may happen on using `parent_of`\`child_of` when there is a
recursion in the tree (e.g. a record is marked as a parent of itself). Fix it by
excluding seen records from the next iteration.

2.

Another problem with `child_of` is `parent_id` that references to another model.
For example, the `parent_id` may come from inherited model. It's the case with
`res.users` and `res.partner` models. It may lead to a random search results.
Avoid that by raising exception in case of wrong usage of the `child_of`
operator.

STEPS:

In demo data, there is a partner called "Wood Corner" that is `res.partner(9,)`
that has 3 sub-contacts. If we give Portal access to two of them, we end up with
a database, where we have a `res.users(9,)` record that has a partner, which has a
`parent_id` to "Wood corner". So this way, the user id is the same as the user's
partner's parent contact id.

After that open a shell and type:

```
env['res.partner'].search([["user_ids", "child_of", 9]])
```

BEFORE: infinite loop (without change n.1) or random search results (when change
n.1 is applied)
AFTER: ValueError exception

---

opw-2729740

closes odoo/odoo#122080

X-original-commit: 3c9b3457
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>

This reverts commit 12355a80042c70d.

Following of the next steps https://www.odoo.com/web#id=3338017&cids=1&model=project.task&view_type=form



Initial opw-2992106

closes odoo/odoo#122431

Signed-off-by: William André (wan) <wan@odoo.com>

When duplicating the reco model, we want to counterpart entry lines to be copied as well.

closes odoo/odoo#122332

X-original-commit: c5d5f4db
Signed-off-by: William André (wan) <wan@odoo.com>

The selection function get_selection_class for the field classname has
obviously been thought to be overridable by subclasses in order to add
new selection classes if need be.

However, before this commit the method was passed directly to the
Selection constructor, which used the callable object directly. If it
was overridden by a subclass, the Selection object would still use the
same non-overridden callable instance.

With this commit, we give the name of the method instead of the
callable, which makes that the method is resolved after all overrides,
and therefore the resulting selection will be the overridden one.

closes odoo/odoo#122341

X-original-commit: 91bea596
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Paul Morelle (pmo) <pmo@odoo.com>

Before this PR, when multi vat was activated and a foreign vat number was set on
 a fiscal position it was not printed on the invoice for the following layout:
 Striped, light and boxed. The Bold layout is not impacted since it does not use
 company details.

 This PR adds the foreign vat on the invoice when it's necessary.

closes odoo/odoo#118782

Task-id: 3248767
Signed-off-by: John Laterre (jol) <jol@odoo.com>

If applied, this commit will solve the min-max issues for efaktur.

- invalid literal for int() with base 10: when we enter all characters
string in the min or max it will raise an error like this.

- Error is also raised when the min or max is blank and try to save the
record.

So, I have update the value as 0 if the min value or max value not
generated.

see - https://tinyurl.com/2lx9j2kr



Sentry - 3936020226

closes odoo/odoo#122278

X-original-commit: 78ecfd66
Signed-off-by: William André (wan) <wan@odoo.com>