closes odoo/odoo#97362

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

Steps to reproduce:
- Create a quotation
- Add a product that is invoiced on "ordered quantities" and set the
  quantity to a negative number.
- Leave 'delivered' to 0
- Confirm the quotation
- Create the Invoice and validate it.
- Go to the SO list view (Orders > Orders)

You should see that the Invoice Status of the order you just created is
'Upselling Opportunity', which is not correct.

Why this is happening:

Here's an explanation on the 'Upselling Opportunity' state (found in
the code):
" upselling: this is possible only for a product invoiced on ordered
quantities for which *we delivered more than expected.* "

In our case, the invoice line's state is set to 'upselling'
because we have a negative ordered quantity and a zero delivered
quantity (i.e. we delivered more than expected)

opw-2895218

closes odoo/odoo#97015

Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>

closes odoo/odoo#97520

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

Steps to reproduce:

1. Go to Inventory-->Settings-->Check option to "Display Lots & Serial
Numbers on Invoices"
2. Go to Rental App
3. Create a new Rental Order for a product that is tracked by Serial
Number. Pop up shows up. Also something to note here, though not
necessarily related to this ticket, but you cannot select available
serial number from this pop-up. It doesn't let you choose anything
even when there are multiple serial number available/in stock.
4. Confirm the order.
5. Validate the Pickup and set the Serial Number in the popup.
6. Create the invoice.
7. Confirm the invoice.
8. Print "Invoices without payment"

Bug:

in https://github.com/odoo/odoo/commit/7a030f616f7e04b3994fc718840d265b1dd21068



the filter functions were removed. They had the effect
of making sure that the sml is either a delivery or a return
by filtering on `sml.location_id.usage` and
`sml.location_dest_id.usage`

Fix:
check if the product is a delivery or a return by
making sure that either of `sml.location_id.usage` and
`sml.location_dest_id.usage` is `customer`

OPW-2936505

closes odoo/odoo#97449

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

Steps to reproduce:

  - Switch odoo language to french
  - Create a client bill for Azure Interior of $1 000 000
  - Confirm it
  - Go to the accounting dashboard
  - On the bank, click on reconcile
  - Select Azure interior
  - Click on the correct bill
  - Switch to Manual operations
  -> $1 000 000 is not a correct monetary field

Cause of the issue:

  Recently in https://github.com/odoo/odoo/pull/94126

 , `formatMonetary`
  switched from joining the currency and symbol from ` ` to a non
  breaking space, NBSP.
  To parse monetary values, the behavior was to split around NBSP to
  get the symbol on one side and the value on the other which is then
  passed to `parseFloat`.

  For the following examples, NBSP is replaced with an underscore.
  So `$_1000` becomes `$, 1000`
  But some languages such as french uses the same char as thousands
  separator.

  In that case, `$_1_000` becomes `$, 1, 000` and then the parse fails.

opw-2937403

closes odoo/odoo#97425

Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>

This old file is indented with tabs instead of spaces.
This is a problem because the file is using as template to
write new localization.

closes odoo/odoo#97412

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

Before this commit, importing an .OFX file from BNP failed because the account number format is not the same.

This is a problem on BNP's side but it is blocking for our clients and needs to be fixed.

This commit fixes this by checking that the account number corresponds to a specific part of the IBAN (for France only).

Task id 2860720

closes odoo/odoo#97413

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

Sometimes, no picking type match the domain, but picking_type_id is a required field.

closes odoo/odoo#97230

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

backport of  #85323

closes odoo/odoo#96201

Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Co-authored-by: auon-odoo <auon@odoo.com>

Steps to reproduce:
	- Install contact,l10n_in
	- Create a new contact with no country
Issue:
	- The state ID is now mandatory when there is no country
Solution:
	- Modify the xml to remove the condition for no country

opw-2882164

closes odoo/odoo#94071

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

It is currently impossible to modify the _cart_update behavoiur from website_sale_stock

The sale.order method _cart_update() updates the lines on the e-commerce shop
cart, some modules override the method adding new features, the module
website_sale_stock is one of them.

The specific behavior of _cart_update() in the module website_sale_stock allows
to delete from the sale order the products whose demand is greater than the stock.

If the specific behavior of the module website_sale_stock is needed to be
expanded or totally changed, that is not possible because the method _cart_update()
should be always super called, even if the website_sale_stock code for
_cart_update will be totally changed.

To allow inheriting just the specific behavior of website_sale_stock without
affecting other modules. This commit creates a new method _cart_lines_stock_update()
which have the important behavior for this module and will allow to be
easier to inherit it.

Based on: https://github.com/odoo/enterprise/commit/f5d92e70aaa472324cc1f0374ddb108d100bec59



OPW#2500355

closes odoo/odoo#68854

Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

Original PR: #96572

closes odoo/odoo#97163

Signed-off-by: Kevin Baptiste <kba@odoo.com>

Check whether the product ID of the first item exists inside product_data
before trying to access it. Although it means the first item still does not
appear, both products will be present in the user's cookies.
When the user refreshes the page or navigates away, both products will be
visible in the comparison panel.

closes odoo/odoo#64259

Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

When getting the on hand quantity of a product in a specific location,
the result may be incorrect.

To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create a storable product P
3. Update its quantity:
    - 5 x P at WH/Stock/Shelf 1
4. Inventory > Reporting > Inventory Report
5. Apply the following filters:
    - Product: P
    - Location: WH/Stock/Shelf 1
    - => There is a line with 5 x P at WH/Stock/Shelf 1, which is
correct
6. Click on Inventory at Date, set <Today>, confirm
7. Apply the following filters:
    - Product: P
    - Location: WH/Stock/Shelf 1

Error: There is a line for P but its on hand quantity is 0, which is
incorrect (should be 5)

In the first search, we let the ORM handle the domain conversion. When
searching for `('location_id', 'ilike', 'WH/Stock/Shelf 1')`, it will
use the `_rec_name` of the model to find the record. In case of a stock
location, its `_rec_name` is the field `complete_name`:
https://github.com/odoo/odoo/blob/94a8ad3fae914b046064bb7ce17572be8280f6e0/addons/stock/models/stock_location.py#L19



However, for the second search, when getting the on-hand quantity of the
product, we force the use of the field `name` to find the location.
Because the `name` of the searched location is "Shelf 1", using
"WH/Stock/Shelf 1" as key search will not work.

OPW-2920904

closes odoo/odoo#96827

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

When redirected to the payment acquirer PayuLatam, if the amount is more than 2
decimals we can have two errors (invalid sign and unique reference).
Even with the decimal accuracy set to 2, we still can have a rounding issue and get
an amount like 1661.340000001

fixes opw-2900105

closes odoo/odoo#96947

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

this fixes the domain of document types for vendor bills, (was failing since it included
invoices as a document type as option for
credit notes in the wizard and also fixes the opposite (credit notes in invoices generation)

closes odoo/odoo#91022

Related: odoo/enterprise#27165
Signed-off-by: Josse Colpaert <jco@odoo.com>

Only youtube and dailymotion were able to add this property to their
video. Maybe it was not supported by vimeo back then, but it seems to be
supported now.

It improves the vimeo youtube in two ways:
1. For background video, the controls are now hidden. There were visible
   for a few seconds before this PR which is not ideal
2. For non background video, there were no way to hide the controls
   which might be problematic to some users as in mobile there is the
   controls display but also an ugly "Tap to unmute" in the middle of
   the video.

Step to reproduce (background video):
- Drag & drop a "Text - Image" snippet and add it the biggest possible
  padding, also add padding to the image (so you see the full video and
  not just part of it)
- Double click on the image, then on the video tab insert a vimeo url
- Save, you will see the controls for a few seconds (progress bar, video
  title, link to vimeo, etc)

Step to reproduce (non background video):
- Drag & drop a "Text - Image" snippet and double click on the image
- On the video tab, insert a vimeo url
- Select "Auto Play"
- Save and go to mobile, you will see the controls and an ugly "Tap to
  mute" in the middle of the video.

The "Tap to mute" is a browser feature, not a vimeo feature. Browsers
are muting video by default when auto play.

Still, some people want to have a nice auto play video shown to users
without sounds and don't want that overlay/controls.

opw-2901256

closes odoo/odoo#96434

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Steps to reproduce:

  - Install Studio, Contacts, l10n_in
  - Go to Contacts, open studio on the form view
  - Edit the GST Treatment field name
  -> No changes are made

Cause of the issue:

  When combinings views to generate the final arch, extensions are
  ordered by priority. Studio edits have a priority of 99 but in this
  case, there is an override with a priority of 100.

opw-2899654

closes odoo/odoo#96638

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

When a user exports a picking with the option 'import-compatible', he
won't be able to import the record later.

To reproduce the issue:
(Need stock. Use demo data)
1. Inventory > Operations > Transfers
2. Select a transfer (without opening it)
3. Action > Export:
    - Enable the option "import-compatible"
    - Add the field "Operation Type"
    - Export the transfer
4. Back to the transfers list view, click on Import
5. Load the exported file and click on Test

Error: An error message is displayed ("No matching record [...] in field
'Operation Type'"). However, the option "import-compatible" was enabled
and the operation does exist, so the record should be found.

When exporting a record, if one of the selected fields is a relational
one, we use its `display_name` as value:
https://github.com/odoo/odoo/blob/5797fd80a63309269f15bcbe4948d4429a53eec2/odoo/models.py#L883-L886
Then, when importing, we use `name_search` to retreive the record:
https://github.com/odoo/odoo/blob/662ecf4e20ceab92b62804cb2a06e51f6b897623/odoo/addons/base/models/ir_fields.py#L406

Back in the use case: if an operation type has a warehouse, its display
name will be the combination of the warehouse name and its name:
https://github.com/odoo/odoo/blob/b6833702044b0d3057d543dae71fbea7ef091d98/addons/stock/models/stock_picking.py#L146-L151
However, the `_name_search` does not handle this type of search key:
https://github.com/odoo/odoo/blob/b6833702044b0d3057d543dae71fbea7ef091d98/addons/stock/models/stock_picking.py#L157-L164


Therefore, using that value ("Warehouse: Operation name") in this
`name_search` will not work.

According to the review from odoo/odoo#95526, such a model is considered
as broken: "if the display name (`name_get`) is overridden, then the
`name_search` should be overridden to match". Moreover, the generic
solution proposed in the previous PR would not work in case of
multi-warehouses.

OPW-2739786

closes odoo/odoo#96087

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

When displaying the price of a shipping method, if its type is "Fixed
Price", the option "Tax-Included" is not considered.

To reproduce the issue:
(Use demo data)
1. In Settings:
    - Product Prices: Tax-Included
2. Create two shipping methods:
    - SM01:
        - Provider: Fixed Price
        - Set a customer tax of 15% on the associated delivery product
        - Fixed Price: 100
        - Published: True
    - SM02:
        - Provider: Based on Rules
        - Set a customer tax of 15% on the associated delivery product
        - Pricing:
            - If weight >= 0: Cost = 100 + 0 * weight
        - Published: True
3. Open the eShop
4. Add the Customizable Desk to the cart
5. Process checkout

Error: When displaying the delivery methods, the price of SM01 is
incorrect: $100 instead of $115. In other words: the tax is not in the
price, as it should according to the settings. (The price of SM02 is
correct: $115).

The displaying of the shipping method price depends on the shipping
method type:
https://github.com/odoo/odoo/blob/68b08164e5de353ea0c48de92d0c0e028b49bc52/addons/website_sale_delivery/views/website_sale_delivery_templates.xml#L35-L46
If the type is `fixed`, we display the `fixed_price` field of the record
(that is the value encoded on the shipping method form, so it does not
include any tax)
If the type is different, we just display a text: "Select to compute
delivery rate". And, when loading the page, a JS widget gets and
displays the rate for each shipping method (including SM01!)
https://github.com/odoo/odoo/blob/204a2bb5553a275e785fbb9ccefbe26b06ef4ba1/addons/website_sale_delivery/static/src/js/website_sale_delivery.js#L38-L47
And in that case, the rate returned by the RPC includes the tax (if
needed):
https://github.com/odoo/odoo/blob/bc2615d8ab5135f21c488c5a260c59605b0da498/addons/website_sale_delivery/controllers/main.py#L57-L60
That is the reason why the displayed price of SM02 is correct.

When the widget gets the prices, it uses the classes to find and replace
the rate with the one returned by the server:
https://github.com/odoo/odoo/blob/204a2bb5553a275e785fbb9ccefbe26b06ef4ba1/addons/website_sale_delivery/static/src/js/website_sale_delivery.js#L95-L105


However, if the shipping method type is `fixed`, it does not have the
class `o_wsale_delivery_badge_price`, so the SM is not found and its
type is not updated (that explains why the displayed price of SM01 is
not correct).

Because the widget gets the rate of all shipping methods, we should take
advantage of that and let the widget apply the result on each method,
even if the type is `fixed`

OPW-2854341

closes odoo/odoo#96021

Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

Definition of reconciled line was recently changed [1] and draft records are not
marked as reconciled anymore. However POS session closing still needs old
definition of reconciled line, because state of the related journal entry is
still draft and hence `reconciled` value is always equal to `False`.

STEPS

1. POS -> Open Session -> Order -> Invoiced
2. Backend -> Open Order - Return Products -> Payment -> Invoiced
3. Close session

BEFORE: error *You are trying to reconcile some entries that are already reconciled.*
AFTER: POS Session is closed successfully

But previous commit fixed it. This commit only adds a test.

[1]: https://github.com/odoo/odoo/commit/1d73bc7d5458b3bb3a566aa4b4a4b101a5329b9a



opw-2859747

closes odoo/odoo#92666

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

Fine-tuning of https://github.com/odoo/odoo/commit/c8c3aa96e18827c3c032540b92e95b27bbed0fc3.

Also, in auto_reconcile_lines, consider case of having aml without credit, debit and amount_currency.

Part-of: odoo/odoo#92666

Steps:
- Go to inventory
- Transfers
- Add to dashboard
- Open dashboard
- traceback

These views use allowed_company_ids but this key is not present in
params/action context.

Instead of adding it in the window action like here https://github.com/odoo/odoo/pull/88851


we can use the `session.user_context`.

opw-2908348s

closes odoo/odoo#96096

Signed-off-by: Géry Debongnie <ged@odoo.com>

Description of the issue/feature this PR addresses:
When tax is configured to be "Include in Price", the e-faktur document violates official regulation. Prices columns in e-faktur has to be declared without tax inclusion. Current code does not differentiate behaviour when "Include in Price" configuration in tax is True or False.

Current behavior before PR:
When tax is configured to be "Include in Price", the prices columns (unit price and the total) includes tax, which violated the e-faktur documentation rule. Consequently, the calculation for discount will be flawed since the current discount amount computation is (price_unit * quantity) - price_subtotal.

Desired behavior after PR is merged:
Price columns (unit price and total) should no longer include tax, and will result to correct discount amount calculation.

Task:
2889400

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

closes odoo/odoo#94114

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

Steps to reproduce the bug:

- create a storable product “P1”:
    - Go to  purchase tab > add vendor “azure interior” with price of
    $10 per unit
- Create a PO:
    - Select Azure interior as vendor
    - add 3 units of P1:
         - update the price from $10 to $5 unit price
    - Confirm the PO
   - Receive order
   - Create a Bill and confirm it
- Go back to the Po:
    - The unit price is readonly
    - Change the quantity from 3 to 5
Problem:
The price is updated to 10 in the onchange_quantity

Solution:
If the PO is in the invoiced status, it's useless to update the unit
price, because anyway, the field is readonly, it will not be saved
when the user saves the PO

opw-2920050

closes odoo/odoo#96294

Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

TT34416

closes odoo/odoo#96391

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

When using _prepare_analytic_distribution_line, it would take
the company for the line from the distribution, then the env.
This would cause multicompany issues in some case, creating the
line for the wrong company. By using current the move line to
get the company before falling back on the env, we can avoid such
an issue.

OPW-2900827

closes odoo/odoo#96381

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

Before this commit, importing an .OFX file from BNP failed because the account number format is not the same.

This is a problem on BNP's side but it is blocking for our clients and needs to be fixed.

This commit fixes this by checking that the account number corresponds to a specific part of the IBAN (for France only).

Task id 2860720

closes odoo/odoo#96025

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

Before this commit when multiple instances of the same product
were selected in a PoS session, `can_be_merged_with` checked if they
had the same price before merging them in a single order line. However
the order line prices were not rounded. In the case of a floating
point error in order line price calculation, this behavior resulted
in multiple order lines for the same product.

Steps to reproduce the issue:
1. Create a product
2. In the pricelist, create a formula of -10% discount based on cost,
and set the cost as 136.35 $
3. Open a POS session, add the product multiple times
4. The products are not combined in one group, each creates their
own order line

To fix this issue, we need to round the order line prices in this
function.

opw-2854304

closes odoo/odoo#95813

Signed-off-by: Masereel Pierre <pim@odoo.com>

Browsers don't render html entity in the "title" attribute and we cannot use
them. Otherwise we may get values like "$ 100".

Fix it by using special character and not html entity. It works both in html
strings and attributues

The problem was reported here:
https://github.com/odoo/odoo/pull/90191#issuecomment-1156034355

STEPS: open invoice and put pointer over monetary field in the list.

Note, that to reproduce the problem, the widget should not be specifed
explicitly. See
https://github.com/odoo/odoo/blob/5b9fada39913cd456a3659faef1160f84ae19860/addons/web/static/src/js/views/list/list_renderer.js#L436-L439
https://github.com/odoo/odoo/blob/5b9fada39913cd456a3659faef1160f84ae19860/addons/web/static/src/js/views/list/list_renderer.js#L452-L456



closes odoo/odoo#94126

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

The product configurator doesn't allow you to use non-integer quantities

Steps to reproduce:
1. Install Sales
2. Go to Settings > Sales > Product Catalog and enable Product
   Configurator
3. Go to Sales > Products and create a product 'Product A' with
   attribute Color and at least two values
4. Create a Quotation and add product 'Conference Chair (CONFIG)'
5. In the product configurator, specify 3.5 as quantity and click on
   'ADD'
6. The total price is wrong
7. Add the optional product 'Chair floor protection' and confirm
8. The quantity of 'Chair floor protection' rounds to 3

Solution:
Parse the quantity as a float instead of an integer (and replace
potential commas to dots in case of different decimal separator), get
the quantity from default_quantity for the rpc call (as it was converted
to an integer because of its type) and convert the quantity to float in
the controllers

Problem:
parseInt was used to retrieve the quantity and the controllers converted
the quantity to an integer. The field quantity of the
SaleProductConfigurator is of type Integer, which rounded the quantity
when opening the configurator.

opw-2896367

closes odoo/odoo#96050

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

Steps to reproduce:

1- install sale, accounting
2- create a fiscal position fp that maps
tax inc t1 to any other tax t2
3- create a delivery product dp with t1 and mark it "can be sold"
4- create a new delivery method with dp
5- in a new sales order, choose fp, click on add delivery
6- the unit_price is wrong, it hasn't mapped t1 to t2
7- try adding the delivery as a product in a new sales order line
8- the unit_price is correct and the taxes are correctly calculated

Bug:

 `_create_delivery_line` is not using the same logic used
 when normally adding a sales order line although technically
 delivery product is still a product

Fix:

use `_get_tax_included_unit_price` to get the correct unit_price

OPW-2806965

closes odoo/odoo#92263

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

By enabling the method '_employee_values_sync' the original behavior is
keep. Furthermore, by overriding the method now is possible to decide
either a field is synced or not into employee.

closes odoo/odoo#95159

Signed-off-by: Kevin Baptiste <kba@odoo.com>

How to reproduce the bug ?

- install accounting and contacts
- Create a second company
- In the contact app, create a new contact.
- As company 1, add a bank account for this contact
- Switch to company 2 and add a bank account for the same contact
- In the Accounting app, create a new bill
- Select the contact created earlier as partner.

What is the bug ?

In a multi company environment, if you have a contact accessible with
several companies who have defined a bank account for him, you get an
error when you select this contact as partner. The reason is the fact
that the account of the other company is selected.

opw-2893122

closes odoo/odoo#95334

Signed-off-by: Adrien Minet <admi@odoo.com>
Signed-off-by: Minet Adrien (admi) <admi@odoo.com>

When both a specific inheriting view and a non-specific base view are
written simultaneously, the specific inheriting base view must be
updated even though its id will change during the COW of the base view.

This commit sorts the list of written views in order to first handle the
website-specific ones then the base ones which might change some of the
ids of the already updated view.

Steps to reproduce in 14.0+ (no scenario found in 13.0):
- Create a new website.
- Configure the language selector layout to "Inline".
- Configure the language selector layout to "None".
=> Error notification was displayed and change was not applied.

task-2885882

closes odoo/odoo#93940

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

Currently,  two lost buttons will appear, if you go to the form view of a lead that has 100% probability. The difference between the two duplicated "Lost" buttons is that one ask for a "lost reason" before marking a lead/opportunity as lost, the other does not.

After discussing with the PO for CRM, it appears that the button that asks for a "lost reason" should not appear on a lead. This commit makes the necessary changes to reflect that behavior.

opw-2886623

closes odoo/odoo#95911

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

The tax group in version 13 doesn't have country_id field yet.

Oversight of 4aa3c140.

closes odoo/odoo#96061

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