We made the field cumulated balance non exportable
in the GL.

Steps:

- Go to Accounting->Accounting->General Ledger
- Unfold and select one or several lines
- export lines
-> The cumulated balance is not computed

The reason is we don't pass in the compute as we don't
come from the search_read method when exporting, so we don't have a domain
to compute the cumulated balance.
As we can't force the domain, we override the fields_get method
to make the field non exportable.

opw-2800669

closes odoo/odoo#91527

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

closes odoo/odoo#104891

Signed-off-by: Djamel Touati (otd) <otd@odoo.com>

This commit fixes premature usage of `purchase_price` field on
sale.order.line model, before its definition in sale_margin module.

Since this test requires both sale_mrp and sale_stock_margin to pass,
this commit adds an auto-install bridge module that solely address this
issue.

Steps to reproduce:
- Install sale_mrp module
- Run tests (at least .test_kit_cost_calculation)

Problem:
Traceback:
AttributeError: 'sale.order.line' object has no attribute 'purchase_price'

See odoo/odoo#100126

Part-of: odoo/odoo#104891

closes odoo/odoo#104402

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

closes odoo/odoo#104076

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

### Steps to reproduce
* go to Accounting > Settings and activate 'Cash Basis'
* got to Chart of Accounts and create a new  account of type
  `Current Assets`. We'll call it `A`.
* create a new tax, we'll call it `T`, with the following parameters:
  * Tax type: Purchases
  * Tax computation: Percentage of Price
  * Amount: 22%
  * Distribution of invoices:
    * add a line with the following parameters:
      % = 40, Based On = 'of tax' and Account = the tax paid account.
    * add a second line with the following parameters:
      %= 60, Based On = 'of tax'
  * Distribution of Credit Notes: Add the same lines as
    'Distribution of invoices'
  * In the Advanced Options tab, set :
    * Tax Eligibility = 'Based on Payment'
    * Cash Basis Transition Account = `A`
* create a new vendor bill and add a product line to it and set
  Taxes = `T` on that line
* confirm and register payment

Now go to Accounting > Journal Items, group by Journal. Look through the
'Cash Basis Taxes' group and find the entries related to the vendor bill
you just made. One of the debit lines on account `A` is not correct.
Here, the account should be the one specified on the invoice line.

opw-2796727

closes odoo/odoo#103631

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

This commit is to compute correct lot number for serial/lot tracked
products on refund invoices

Reproduction:
1. Install Sale, Accounting, Inventor. In setting of Inventory, enable
Lots & Serial Numbers, Display Lots & Serial Numbers on Invoices,
Display Lots & Serial Numbers on Delivery Slips.
2. Create a product with lot/serial number
3. Create a order of this product, confirm. Click the delivery and
validate it.
4. Back to the SO, create an invoice, confirm and print it, the serial
number shows.
5. At the invoice, click “Add credit note”, choose “Full refund” (2
invoices for the SO) or “Full refund and new draft invoice” (3 invoices
for the SO), the lot number doesn’t show in new draft invoice or the
refund invoice

Reason: the current lot number tracking workflow focused on invoicing
different numbers of products and making sure it gets the correct
lot/serial number. It doesn’t include the refund invoice case.

Fix: since the current working logic works great with invoicing products
which are delivered from the warehouse to the customer, we can reuse
this logic for refund invoices for products which are returned from the
customer to the warehouse. In the refund and return case, we switch the
calculation of warehouse and customer. Thus, a return can be seen as a
delivery from the customer to the warehouse.
In the code, we set a new variable, return_source_usage, to check if the
account move type is a delivery or a return. If it’s an invoice for
return, we take the opposite of the previous invoiced product quantity.
Because in a refund, previous invoiced is now considered as refunded.
In the original workflow, when sml.location_id.usage is “customer”, it’s
a return and we update the returned_qty and the related quantities. In
the new workflow, if the invoice is a refund one, we do the same steps
when sml.location_id.usage is “internal”, e.g. when the stock move line
is a delivery, we consider it a return.

For refund invoices. There are two choices of refunding:
1. refund and a refunding invoice: 2 invoices for the order, one is the
original one, another is the refund
2. refund and create a new draft invoice: 3 invoices for the order,
original one, a new draft one and the refund.

In the second case, we will create a new draft invoice. If we simply
apply the original work logic, the lot number will not be printed on the
draft invoice. This is because the previous amls list includes its
original invoice. We have to filter out the duplication of the same
invoice to print the right lot number for the new draft invoice.

Added the report test for two refund cases, one for cancel (Full refund)
and another for modify (Full refund and new draft invoice)

opw-2879714

closes odoo/odoo#99691

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

The valuation field of the product_id is company-dependent.
If the user validate the picking in multi-company context with his current company != picking company, then the checks may fail, and the account move can not be created.

closes odoo/odoo#105149

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

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>