Steps to reproduce:
 - Install website_sale_coupon
 - Load demo data
 - Create a promotion program that applies on the order
 - Go to the webshop and add 2 different products to the cart

Bug:
The line of promotion is in second place, instead of at the end.

Fix:
move the old sale order line to the end if it applies on all the order

opw-2985632

closes odoo/odoo#105249

X-original-commit: 5456f198
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

To Reproduce
============

- enable QR code on Accounting settings
- with a customer who has a bank account create a credit note for him/her
- in other info tab, make sure that the qr code method is empty
- send or print the credit note

The Problem
===========

the qr code method field will be filled with SEPA, and a QR code will be added to the PDF

Solution
========

Generating a QR code for a credit note doesn't make any sense, so the qr code method field must be hidden
and no QR code should be generated.

opw-3010649

closes odoo/odoo#104496

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

Since the provider only accepts A4 letters, prevent the user from using
non A4 formats by giving them an error when clicking the Send button.

closes odoo/odoo#105150

X-original-commit: e03fae1f
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>

Pingen does not support localized country names, as such we need to force English locale.

closes odoo/odoo#104857

Signed-off-by: Florian Daloze (fda) <fda@odoo.com>

Issue :
- When sending an sms reminder by cron user, `_get_display_time` is
used which always uses Odoobot (cron user) timezone regardless of the
partner timezone

Fix:
- use `partner_id.tz` instead of Odoobot

OPW-2991624

closes odoo/odoo#100733

Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>

Steps to reproduce:
1-set language to an LTR language (arabic / hebrew...)
2-select any field with the date-time range widget (eg: planning>add)
3-the hour and the minute selection is reversed.

Bug:
the hours and minutes order depends on the language orientation where
they should always follow this format HH:MM

Fix:
force the time to be displayed Left To Right regardless of language

opw-2953221

closes odoo/odoo#100320

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

The wizard would update the amount and payment_difference in multiple
cases as the fields get updated by the user.
In multicurrency, the base amount would be converted to the selected
currency at the date of the payment selected by the user.
If the date is emptied before changing the currency, this would lead
to a traceback when calculating this amount.

In order to fix that, we can fall back on today as date to convert
the amount, which will avoid a traceback and won't impact the result
since the amounts will be updated again when the required date field
is filled.

Fixes https://github.com/odoo/odoo/issues/92114



closes odoo/odoo#105113

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

Steps to reproduce:

  - In odoo, create an event "example" in the future with alice@outlook.com and add
    bob@outlook.com to the attendees
  - In the bob outlook account, there should be an ics file with the
    following email "Invitation to example"
  - Drag and drop the ics file into outlook calendar
  -> Bob is set as the organizer

Cause of the issue:

  The organizer property is missing from the ics file
  cf https://www.rfc-editor.org/rfc/rfc5545#section-3.6.1



opw-2841276

closes odoo/odoo#100426

Signed-off-by: Arnaud Joset <arj@odoo.com>

Those tags should only be created by the tax reports; creating them manually makes no sense.

closes odoo/odoo#105005

Signed-off-by: Laurent Smet <las@odoo.com>

Taxes on self-invoices for non-EU export actually have amount > 0,
l10n_it_has-exoneration = False but they must have the law reference
field filled out, so we're taking the "invisible" clause
out of the view.

Task: https://www.odoo.com/web#id=3010849&model=project.task


opw-3010849

closes odoo/odoo#104745

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

- add philippines localization

task-2713149

closes odoo/odoo#81280

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

Part-of: odoo/odoo#81280

To reproduce the issue:
1. In Settings, enable UoM
2. Edit the UoM 'Dozens':
    - Rounding: 1.0
3. Create two products P_finished, P_compo:
    - P_finished:
        - UoM: Dozens
4. Create a BoM:
    - Product: P_finished
    - Qty: 1 x Dozens
    - Compo: 1 x P_compo
5. Create and confirm a MO for 1 x P_finished
6. Edit the MO:
    - Set the producing qty to 1
    - Set the 'to consume' quantity of P_compo to 1.23

Error: the consumed quantity of P_compo is still 1.0 (it should be
1.23). If the user tries to set the quantity to 1.56, the consumed
quantity will become 2 (also incorrect, should be 1.56)

The UoM used to round the new consumed quantity of the component is
incorrect. Considering its definition:
https://github.com/odoo/odoo/blob/0fdd35cfb5c7145b3a7a855956004e38de7c6e2a/addons/mrp/models/stock_move.py#L164-L170


the UoM of `unit_factor` is `UoM_sm / UoM_mo`. Therefore, in
`_update_quantity_done` (see diff), when we compute `new_qty`, we have
(in terms of UoM) `(UoM_mo - UoM_mo) * UoM_sm / UoM_mo`. So, the value
is already in the correct UoM (`UoM_sm`) and we just have to round it
based on that UoM

OPW-3016837

closes odoo/odoo#104751

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

Before this commit, performing a search in a m2o can block your ui
despite the result already being displayed.

Why?
When you perform your search in a m2o, a set of RPC queries are made
with the different search values (name_search). If the last search value
(the one that will be used by the m2o in its autocomplete) has already
been resolved, but one of the other RPCs has still not been resolved,
then the screen will remain blocked until all the rpc's have been resolved.

Solution:
Since we are only interested in the last rpc, we will cancel all the
others. So with each new rpc, we will cancel the previous one.

How to reproduce:
- Go to a form view with a m2o field
- Edit this field +- slowly (several rpc will be done with different values)
- Receive the result of the search. (The autocomplete is displayed with
     the right values)

Before this commit:
If one of the other rpc's is not yet resolved, the ui will block
until all rpc's are resolved.

After this commit:
The ui will not block.

closes odoo/odoo#104415

Signed-off-by: Samuel Degueldre <sad@odoo.com>

Previous fix for self invoice RegimeFiscale = RF18
didn't take into consideration the test that was specifically
targeting it, so now it's broken in v14.
The other versions are safe as the staging does run the l10n tests.

closes odoo/odoo#104942

See: https://github.com/odoo/odoo/pull/104780


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

The scheduled end date of a work order is not consistent with its
scheduled start date when starting the work order

Steps to reproduce:
1. Install Manufacturing
2. Go to Settings > Manufacturing > Operations and enable Work Orders
3. Create a manufacturing order for any product, with any component and
   a work order
4. Confirm and plan the MO
5. Edit the scheduled start date of the work order to the next working
   day and save
6. Start the work order
7. The scheduled start date changes but the scheduled end date doesn't

Solution:
When starting a work order, change the `date_planned_finished` according
to the new `date_planned_start`

opw-3005767

closes odoo/odoo#102809

Related: odoo/enterprise#32619
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

[FIX] l10n_fr_fec,[l10n_]account_edi_ubl_cii[_tests]: fix factur-x tests and use `default_move_type` key

Fix broken tests due to 2 different commits:

* https://github.com/odoo/odoo/commit/51609d19177c080835116f0ad9c04c33536d926a is adding the `ram:DefinedTradeContact` tag and should thus be added in the test files

* https://github.com/odoo/odoo/commit/de55cfa7098fc1fa07398044cb977f20d213f6da is using the context key `default_move_type` to import any ubl_cii document (and being able to
distinguish between invoice and vendor bills). This key should therefore be added in the tests as well.
We essentially backport the missing code from https://github.com/odoo/odoo/commit/5f78893ad6cf199ce0da72335ce65835d9cd37d9
which was forgotten in 14.0.

Also fix a broken test in l10n_fr_fec due to the renaming of the taxes:
https://github.com/odoo/odoo/commit/85a634c7527f20b56b15c2da90a37dfd637da63b



closes odoo/odoo#104792

Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>

Commit [1] broke some confirm dialogs because the confirm and cancel
callbacks are not called with the same `this` anymore.

E.g.:
- Install website
- Go to the page manager (/website/pages)
- Clone a page (choose a name and confirm)
=> Crash (this.$ does not exist).

Note that this flow was quickly fixed with [2] by changing the local
code instead of fixing the root cause (this commit here actually
technically reverts that change so it keeps working).

The work done at [1] actually needed some more rework than that to
handle two other potential usecases:

- If the confirm dialog handlers' promises are rejected, the dialog is
  not closed (rightfully, like for example allowing to fill an empty
  required input)... but [1] prevented to click on the button again
  forever. With the same example as above, it can be reproduced: if the
  RPC to clone the page fails, I cannot retry.

- If not both confirm_callback and cancel_callback were given, [1] only
  prevented to multi-click on the related button (e.g. if you click on
  "Ok", a RPC which takes 10 seconds is made, you click on cancel
  immediately afterwards -> the dialog is closed while it should be
  prevented (and would be if cancel_callback was given, following [1])).
  That may not be entirely stable to make this change though but it
  seems to make sense and be better (just keeping what [1] wanted here).

Note: this adds some more tests to check all of this + some more things
that were found during development. For example: [1] relied on the fact
that callbacks returned a Promise or nothing... while developers
actually were returning random things (for no reason as no way to get
the result anyway). Adding a test for this prevents to break that in
stable (the first iteration here crashed in such cases).

[1]: https://github.com/odoo/odoo/commit/4b8b079a7d9991a8dc481fe71a45185d672135c9
[2]: https://github.com/odoo/odoo/commit/8216341f5ad8d82ad0bcb0d1f01d874477d2de7b

Closes https://github.com/odoo/odoo/pull/103712


opw-3033878
opw-3043224
opw-3046485
opw-3042542

closes odoo/odoo#104220

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Currently entering custom urls will be missing characters if they contain unicode.

Steps to reproduce:
1. Open Promote dialog
2. Enter a custom url that contains unicode (e.g. `Nội dung có Dấu`)
3. Output: `n-i-dung-c-d-u`

Expected output after this commit: `noi-dung-co-dau`

closes odoo/odoo#104572

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

When the seller is foreign, the Fiscal Regime of the seller must
be set to 'RF18', as per:
https://www.fattura24.com/manuale/altri-documenti/autofattura-fornitori/

Task: https://www.odoo.com/web#id=3010849&model=project.task


opw-3010849

closes odoo/odoo#104780

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

When printing a check that comes from an expense,
the check has no reference to the move from which
the payment has been created.

The reason is that we filter the move by taking
only outbounds to complete the check informations,
but moves from an expense are of type entry.

With this commit, we allow moves coming from
expense to be taken into account by adding a
check on line_ids.expense_id.

opw-3044141

closes odoo/odoo#104493

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

When executing the product2bom method it is possible that an active_test
context is present in self. However, the method should not consider
archived BoMs.

closes odoo/odoo#104495

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

The main motivation for this change is to improve performance of BoM
`explode`, which heavily rely on checking the lines to skip. `explode`
is also called from product `compute_quantities_dict` which is called
multiple times during upgrades. With this fix we improved the running
time of an upgrade _test_ from 3h:30m to 2h:55m which gives a 16%
performance improvement.

The goal of `_skip_bom_line` is to check that for each attribute present
on the line, at least one value associated to that attribute must be in
the attribute values of the product(*). If none is found then we
consider that we can skip the line.

The previous implementation was inefficient. It grouped all values by
attribute, then checked one by one if at least one value is on the
product. In case one attribute does not have any value on the product it
skipped the line.

The implementation we propose here is to take the intersection of the
product and line values, then check that their attributes are the same.
The later can be done with a simple length check. In case they are
different the line must be skipped. Note that this works because only
one value is possible per attribute in a product.

Both implementations are equivalent. The second is more efficient
because does not branch and relies on (record)set operations.

For example, let's consider a product with two attribute values
`a` and `b`, and a line with multiple values `a`,`y` for
attribute 1, and `z` for attribute 2.
```
Product                      Line
+---+                      +-----+
| a | <- same attribute -> | a,y |
+---+                      +-----+
| b | <- same attribute -> |  z  |
+---+                      + ----+
```
This line must be skipped. The reason is that the value `b` is not
among the list `[z]` of values for attribute 2 on the line. The new
implementation would get the intersection of attribute values as `[a]`
from there the comparison of the attributes will fail because `[a]` has
only one attribute while the line has two.

Let's consider a second case, where there is no value on the line for
attribute 2.
```
Product                      Line
+---+                      +-----+
| a | <- same attribute -> | a,y |
+---+                      +-----+
| b | <- same attribute -> |     |
+---+                      + ----+
```
This line is not skipped because there is no value for attribute 2 on
the line. Therefore the condition(*) per attribute is not violated for
this product. The new implementation gets `[a]` as intersection of values,
but now the attributes coincide: they are both attribute 1 for the
intersection and the line.

Finally,
```
Product                      Line
+---+                      +-----+
| a | <- same attribute -> | a,y |
+---+                      +-----+
|   | <- same attribute -> | z,w |
+---+                      + ----+
```
This line is skipped because none of `[z,w]` are in the product. The new
implementation would get again `[a]` as intersection which does not
match the attributes on the line.

closes odoo/odoo#99047

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

The tests in the purchase_stock module include some tests that make sure or
depend on the fact that the price_unit from the generated move lines equals the
price_unit from the purchase order line from which they were created.

However, the price_unit in the move lines exclude taxes (at least those that
have an account set, it uses the total_void computed from the purchase order
line). This means some tests will fail if an installed localization defines
taxes that are included in the price.

The problem is resolved by explicitly creating the test product used in those
tests without supplier taxes.

opw-3033340

closes odoo/odoo#104672

Signed-off-by: Adrien Widart <awt@odoo.com>

Revert this fix, as it was not working as expected, and even
prevent to create a partner.

Revert of following PR: https://github.com/odoo/odoo/pull/103596



closes odoo/odoo#104689

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

closes odoo/odoo#103224

Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

Steps to reproduce:
There is no possibility to reproduce it in test mode
But the flow would be:

- create a company with a NIF not registered
- Set up the EDI invoice
- Create an invoice

Issue:
When the NIF is not registered, is is possible to use it. It will only create an error `approbado con errores` which is apparently fine

Solution:
Whenever the server sent us an '1117' error code, we call again the post_invoice with a new context so we are able to send the request with the right information; that is, the correct ID Type whenever a NIF is not registered.
Indeed, whenever the error code is related to the NIF, is is possible to send again a request without having the invoice defined as "duplicated". It will only go through the process "AceptadoConErrores".

opw-2952108

closes odoo/odoo#104673

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

- Makes the tax more intuitive for the user

Backport of PR #103648
Task-2993525

closes odoo/odoo#104525

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

Loading an non-existing addon directory affect all other modules to be
not loaded. This commit makes sure the path exist before proceed to
explore all the modules under that directory.

closes odoo/odoo#104585

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

In some cases it is possible that a plan is the parent of other plans, for example in Spain. Without this condition, the generate_account_reconcile_model method will be called multiple times and create multiple identical reconciliation models, which is not the expected behavior.

This error has already been fixed in 16.0 in another PR (see: https://github.com/odoo/odoo/pull/99581

), but not in 14.0 and 15.0.

closes odoo/odoo#103260

Task-id: 2982600
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

# Description
The absence of those fields can generate a log note spam & performance issue when updating an order line value.

# HOW TO REPRODUCE
- Create PO with 40+ order lines (50 recommend) (* SA to reproduce would be nice)
- Confirm PO (state needs to be "purchase")
- Update the Ordered Quantity of the first line.
- Save
=> PO Lines from page 2 and beyond have each created the following log message:
"The ordered quantity has been updated."

# Explanation
The purchase.order.line onchange will not save any update on 'price_total' because it is not on the onchangeSpec.
Then a purchase.order onchange is done, and this one does have 'order_line.price_total' on the onchangeSpec, forcing the onchange method to return the field 'order_line' (aka ALL the order lines) as updated.
When saving the changes, the JS framework, who does not have the data for the order_lines on the 2nd page, will not correctly filter the fields with real changes, and add the 'product_qty' field (and more) to the "write" call for every order_line not in the 1st page.
Then the write method, without checking if there is any real change on the product_qty, for each lines that has product_qty in the Write's values, will write in the log note and call a performance intensive method: _create_or_update_picking()

OPW-2982004

closes odoo/odoo#104490

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

Before this PR when you select a pos.payment in custom, it raise.
It doesn't make sens to use api.model here

closes odoo/odoo#99237

Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

Before this commit if a Table of Content entry was a too long word
without spaces, it span beyond the width of the menu part of the Table
of Content block.
Note that in Chrome, during Edit mode the words are already split
across several lines because the `contenteditable="true"` of the
`#wrap` node applies some built-in extra styles (not from user agent
stylesheet) among which `overflow-wrap: break-word;`.

After this commit long words are split across several lines.

task-2965279

closes odoo/odoo#99114

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

closes odoo/odoo#104216

X-original-commit: e058add2
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Signed-off-by: Solan Delvenne (sode) <sode@odoo.com>

Prevent "per line" rounding taxes when tax rounding method is round globally.

closes odoo/odoo#104172

Task: opw-2963947
Signed-off-by: Laurent Smet <las@odoo.com>

Steps to reproduce:

1. Create a product named "Component A" (type = Storable)
2. Create a product named "Kit" (type = Storable)
3. Create a bom for the product "Kit" (type = Kit, lines=1x "Component A")
4. Create a Sale Order, with a sale order line for Kit (qty = 1)
5. Save the Sale Order without confirming it
6. Open a second browser tab, for the same sale order form
7. On the first tab, confirm the sale order
8. On the second tab, confirm the sale order (it's already confirmed in fact but this tab doesn't know it)
9. Go to the deliveries and open the generated picking

Current behavior:
* 2x "Component A" have been added to the picking.

Expected behavior:
* Only 1x "Component A" should be in the picking.

The fix is actually a backport of the commit 6eaea02d merged in 15.0+.

The objective is a little different than the original commit, because we don't really
support automatically decreasing picking quantities from SO after the delivery in 14.0,
however the same patch solves this issue too.

Closes #99659

closes odoo/odoo#99683

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

The clone page behavior in the page properties and the page manager was
changed with [1].
But it was actually not working anymore since [2]  as the input URL
could not be found, so it was crashing (`this.$ does not exist`).

This commit repair that clone page dialog but it is actually only fixing
the consequence of the issue and not the root cause as it should.

A deeper fix fixing the root cause will be done at [3].
In the meantime, this commit will be enough to prevent the issue as we
have more and more opw about that.

[1]: https://github.com/odoo/odoo/commit/4e340cc5f0c1fe9de17a2b852de4faf65a33926a
[2]: https://github.com/odoo/odoo/commit/4b8b079a7d9991a8dc481fe71a45185d672135c9
[3]: https://github.com/odoo/odoo/pull/104220



Courtesy of daramousk for this fix

opw-3033878
opw-3043224
opw-3046485
opw-3042542

closes odoo/odoo#104372

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

Steps to reproduce the bug:
- Create a Kit product "Kit 1":
    - Add a BOM with a component “C1”
    - Add a sales description
- Create another kit product without a sales description "Kit 2":
    - Add a BOM with a component "C2"
- Make sure you have a qty of “C1” and "C2"
- Create a SO:
    - Add "Kit 1" and "Kit 2"
    - Add any other storable product
    - Confirm the SO
- Go to the delivery → validate it
- Print the delivery slip

Problem:
The report doesn’t contain the kit product.

Because in the report, the `stock.move.line` are filtered by checking
the name of their move if it has the same name as the product in
the bill of material, but like the `stock.move` has the name
('description') of the `sale.order.line` instead of the product name,
the lines are filtered and not displayed:
https://github.com/odoo/odoo/blob/14.0/addons/mrp/report/report_deliveryslip.xml#L9



The behavior is the same for purchase orders

opw-2960467

closes odoo/odoo#101953

Signed-off-by: Tiffany Chang <tic@odoo.com>