- Create a product with Category configured with:
  * Costing Method: First In First Out (FIFO)
  * Inventory Valuation: Automated
- Create a PO to buy 1 unit and receive the product
- Create a SO to sell 1 unit and deliver the product
- Return the product
- Re-deliver the product
- Create invoice for SO but don't post it
- Connect with an user with "Accounting: Accountant" rights only
- Post the invoice
An access error will be triggered when trying to access stock valuation layer.

opw-2623376

closes odoo/odoo#76270

X-original-commit: cc76e76e
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>

The method '_company_default_get' on res.company is deprecated and
shouldn't be used anymore.

closes odoo/odoo#76284

X-original-commit: 2842a3c3
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

- Configure payment stripe to be available on the web shop
- Let's consider a product with P (sales price = 100€) invoice policy based on delivered qty
- Set in the config parameter sale.automatic_invoice to True
- Create a SO with P and generate a payment link PL for 50€
- Go to PL and pay it

Bug:

An error was raised because there was no invoicable line when computing the
invoice of SO

opw:2635175

closes odoo/odoo#75892

Signed-off-by: Simon Goffin (sig) <sig@openerp.com>

Currently, when there is a YouTube URL configured on the track, we
automatically set the layout of the track page as "widescreen".

This implies that we hide some menus and adapt the layout to display the full
video player.

However, in the XML template of the track view, we only display the video
player if there is a YouTube URL configured AND one or more of those conditions
is respected:
- The track is configured as a "YouTube Replay"
- The track is "coming soon" (< 30 minutes)
- The track is live
- The track is done

This is done to match the two behaviors and get a consistent display.

Task-2643147

closes odoo/odoo#76248

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

opw-2640962

closes odoo/odoo#76239

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

Following commit 637684fb which improved
the conditions under which the ComponentWrapper compatibility layer
should trigger owl's `__callMounted` on all the owl children of a Legacy Widget.

One case was forgotten though: when the current component (wherever it is in the hierarchy)
is rendered BUT another rendering has been initiated meanwhile.

In that case, we shouldn't mark the component as mounted. The owl's fiber.complete algorithm
will take care of calling __callMounted when it finishes.

closes odoo/odoo#75950

Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>

If for some reason we cannot compute lead probability, we should simply
continue to the next value without causing a division by zero.

For example, this can happen if all stages are team specific, as there is
a current limitation regarding the first stage (used to know how many lost
and won there is) that requires to have no team assigned to it. This is a
side effect of the commit https://github.com/odoo/odoo/commit/cd291b79eb2d2df80899867263ec71438ab8fe87

 introduced in V14, and we should add
a test to ensure we do not crash in that case.

closes odoo/odoo#76110

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Before this commit, Inventory Admin was not able to create new /edit picking type
as Non-admin users doesn't have rights to create/edit sequence.

With this commit, we are creating/editing `sequence_id` with sudo

closes odoo/odoo#75606

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

no need to make rounding during computing qty_available

STEPS (see the test):

* create product with uom dozens
* create product with uom units
* create bom kit to convert one to another
* set qty on hand to 1 for product dozens
* check qty for product units

BEFORE: qty=11
AFTER:  qty=12

---

opw-2632782

closes odoo/odoo#76145

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

`fields.Date.today` doesn't give date based on TZ which might be wrong
in some cases as it doesn't respect TZ.

With this commit, we are using `fields.Date.context_today` as default date.

closes odoo/odoo#75600

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

We fix 2 related UoM issues:

1. Fix quant inconsistency from changing the UoM of Done
   stock.move.lines

Steps to reproduce:
- Enable "Storage Locations" setting
- Create a new "Storable Product" and create a receipt for 1 unit of it
- Validate the 1 unit receieved
- Open "Detailed Operations" of the move and change the stock.move.line
  UoM to dozen.

Expected result: 13 on hand
Actual result: 1 on hand

To fix this:
- prevent users from editing the UoM after the picking is
  done (i.e. unless adding a new stock.move.line and not saving).
- update the write on done logic so stock.move.line UoM changes are
  considering and will update the quant correctly (in case of RPC or
  direct write).

2. Prevent changing UoM of Done stock.move to prevent inconsistent field
values within stock.move and confusion for users

Steps to reproduce:
- Complete a picking (incoming is easiest to see) with a new product
  (i.e. 0 qty) having 1 unit done.
- Unlock picking and add a new stock.move with 1 unit done and save.
- Edit the just added stock.move's UoM from Units to Dozen.
- Check the quantity on hand / Done qty of stock.move after leaving and
  returning to form.

Expected result: 13 On Hand
Actual Result: 2 On Hand and the "Done" qty in the picking is 0.0083
  (i.e. 1/12 of a dozen)

To fix this:
- prevent users from editing the UoM after the picking is done (unless
  adding a new stock.move and not saving)
- if a Done stock.move UoM is uodated, a UserError occurs because there
  is no straightforward way to ensure the quant is updated correctly
  since is handled within the move.line (i.e. has no visibility to its
  move's uom change => changing only UoM and not qty done will result in
  no quant update)

closes odoo/odoo#75891

X-original-commit: 8ca10a8f
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

Calling `_get_answer_score_values` on each question creation or update is
not necessary if value is already provided.

Followup of odoo/odoo@0d32ed45aebe2721073580ddae68ec4a8c1499d6

closes odoo/odoo#68500

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

In a POS session, when using the scanner, if the seller changes the
customer, the prices may become incorrect

To reproduce the issue
1. Create a product P:
    - Sales Price: 38
    - Barcode: 2312345000002
    - Available in POS: True
2. Start a POS session (with debug Window)
3. Scan 2312345010001
    - This is product P with price $10
4. Set a Customer

Error: The price is now $38

Because the price has not been set manually, when changing the customer,
the pricelist is updated and so does the price.

When scanning a barcode that includes a price, the latter should be
considered as manually set.

OPW-2618934

closes odoo/odoo#76076

X-original-commit: e6672427
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

Steps to reproduce the bug:
- Install inventory, purchase and product_expiry
- Create a new storable product that is tracked by lots or serial numbers and expiration date
- Go to inventory > configuration > Warehouse Management > Operations Types
- In “San Francisco: Receipts” > Enable "Create New Lots/Serial Numbers", “Pre-fill Detailed Operations”, and "Show Detailed Operations"
- Create a new RFQ > select the created product > Confirm the order
- Click on “Receipt”

Problem:
In the created “stock_move_line” the expiration date field is not set

Solution:
When we add a new "stock_move_line" and choose a product, an onchange is triggered in order to set
the expiration_date field even if we do not choose a "lot /serial number name".
So we can replace the onchange with a compute function to do the same thing in the creation.

opw-2634583

closes odoo/odoo#75806

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

- create a second warehouse, resupply from the first
- create a product, replenish W2 from W1
- Goto Inventory Forecast

--> Issue value are wrong.

An OUT is when WH source is Set and WH dest is not set.
An IN is when WH dest is Set and WH source is not set.

closes odoo/odoo#67598

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

Also, remove the duplicated 'edi_document_ids' field inside the view.
'edi_document_ids' is now in debug mode for payments.

closes odoo/odoo#75529

Signed-off-by: Florian Gilbert <FlorianGilbert@users.noreply.github.com>

options="{'no_open': '1'}" is managed for many2one fields.
This commit aims to do the same for x2many fields.

Note: A test will be added later
Part-of: odoo/odoo#75529

closes odoo/odoo#75508

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

closes odoo/odoo#75349

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

Because the "Replenishment" can unlink a lot (thousand of
`stock.warehouse.orderpoint`).
and psql needs to check every Many2one `orderpoint_id` constraint
and without index it takes too much time.

opw-2637321

closes odoo/odoo#76030

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

Issue: When creating a manufacturing order and setting a scheduled date
when no workcenter is set, a traceback shows up

Steps to reproduce :
 1) Install Manufacturing
 2) Enable work centers
 3) Create a manufacturing order, in the work order tab, add a new line
 and set a Scheduled Start Date, confirm the date
 -> Traceback

opw-2633940

closes odoo/odoo#75992

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

closes odoo/odoo#75595

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

closes odoo/odoo#75409

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

Reverts 62bf009 as that is causing that no message is posted in the chatter upon creation.
Althought this might have been an issue before, #56631 removed the addition of the "Application created" message in the message body, so now there was nothing adding it, making the message invisible in the chatter.

TT30413

closes odoo/odoo#75978

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

In case a production order loses its procurement group. The backorder
generation process do not have access to the last backorder sequence
used. This commit set a default value to avoid any traceback.

The new backorder  name will not be guaranteed exact related to the
production sequence but will be unique in any cases.

closes odoo/odoo#76060

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

Considering the field declaration:
https://github.com/odoo/odoo/blob/fe5deb4ee4c8e07aed2f2cff6210271bfaa61476/addons/point_of_sale/models/pos_order.py#L1121


`discount` is a rate, not an amount. Therefore, suppose a discount of
10%, when opening a POS-generated SO, the discount shouldn't be "$10".

OPW-2629493

closes odoo/odoo#75991

X-original-commit: 225fb81c
Related: odoo/enterprise#20621
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

Bad debt accounts should be of expenses type like the ones in the l10n_de_skr03 addon

opw-2512526

closes odoo/odoo#76019

X-original-commit: 5780e50c
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Hubert Van De Walle <hubvd@users.noreply.github.com>

Reproduce :
- Create an invoice with a sepa QR-code.

Result :
  When reading the QR-code, German banks assume the fisrt 3 characters are the currency name/code, so the first 3 digits of the amount are cut from this amount.

Solution :
  The amount now starts with the currency name/code (3 letters), as prescribed by EPC norms.

opw-2591454

closes odoo/odoo#75816

Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>

In case there is a `product_qty` column added by a custom module,
`product_qty`, without specifying from which table to take it from
in the view definition, can lead to an ambiguous definition.

```
2021-08-25 12:25:31,624 1145 ERROR db_23001 odoo.modules.registry: Failed to load registry
Traceback (most recent call last):
  File "/home/odoo/src/odoo/13.0/odoo/modules/registry.py", line 86, in new
    odoo.modules.load_modules(registry._db, force_demo, status, update_module)
  File "/home/odoo/src/odoo/13.0/odoo/modules/loading.py", line 424, in load_modules
    force, status, report, loaded_modules, update_module, models_to_check)
  File "/home/odoo/src/odoo/13.0/odoo/modules/loading.py", line 315, in load_marked_modules
    perform_checks=perform_checks, models_to_check=models_to_check
  File "/home/odoo/src/odoo/13.0/odoo/modules/loading.py", line 202, in load_module_graph
    registry.init_models(cr, model_names, {'module': package.name}, new_install)
  File "/home/odoo/src/odoo/13.0/odoo/modules/registry.py", line 370, in init_models
    model.init()
  File "/home/odoo/src/odoo/13.0/addons/stock/report/report_stock_quantity.py", line 126, in init
    self.env.cr.execute(query)
  File "/home/odoo/src/odoo/13.0/odoo/sql_db.py", line 173, in wrapper
    return f(self, *args, **kwargs)
  File "/home/odoo/src/odoo/13.0/odoo/sql_db.py", line 250, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.AmbiguousColumn: column reference "product_qty" is ambiguous
LINE 21: ...AND whd.id IS NULL) OR ls.usage = 'transit' THEN -product_qt...
```

upg-23001

closes odoo/odoo#76020

X-original-commit: 07f0ffad
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>

Steps to reproduce the bug:
- Install sale and inventory
- Create a SO with Qty 10 and confirm it
- Go to the delivery
- Make partial delivery of 5 units and create back-order of remaining 5 units.
- the status of backorder is “waitting”
- Get back to the sale order and cancel it
- the wizard “sale_order_cancel” is displayed, which gives a reminder of some partial deliveries are already done and asks to confirm the cancellation of SO
- Do not confirm the cancellation of SO and click on the cancel button
- Go to the delivery
- The pending deliveries are cancelled

Problem:
The `"action_cancel"` function in the `"sale_order"` model is first called to cancel pending deliveries,
then the `"action_cancel"` function of the `"sale"` model is called, but in that we check if whether one of the deliveries
is already completed in order to display the wizard.

But if the customer clicks the cancel button in the wizard, the SO will not be canceled, but the pending deliveries will already be.

Solution:
Check in the `"action_cancel"` function of the `"sale.order"` model if whether one of the deliveries is already been completed,
if so, do not cancel the pending deliveries and wait for user confirmation in the wizard.

opw-2623404

closes odoo/odoo#75949

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

Steps to reproduce the issue:

- Let's log in Odoo with a user U1
- Create a lead with user U2 as salesperson
- Click on New quotation

Bug:

A SO was suggested with U1 as salesperson instead of U2

opw:2520827

closes odoo/odoo#76009

X-original-commit: a8f1ee59
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Currently, when we try to shorten the links from content with help of
`_shorten_links_text` method, it throws traceback if the body(content)
we pass is `False`(might happen when we directly pass a model field of
textual type but the field doesn't have a value yet). It's because
the `re` expects the content to be string / bytestring.

This commit fixes the issue by adding a check in this method, which
will simply return `False` if there's no body.

Task-2628586

closes odoo/odoo#75987

X-original-commit: 41f59a61
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

When using module `account_invoice_extract`, it would happen that a
bank account of another company was set on the `account.move`.
This happened when the extract update was done in background via the
cron.
A check on the company of the bank account fixes the issue.

opw-2631833

closes odoo/odoo#75989

Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

Steps to reproduce:

  - Install "Field Service" module
  - Go to settings and activate "Recurring Tasks"
  - Go to Field Service -> All tasks and create new one
  - Set for Planned Date : 10/01/2021 14:00 -> 10/02/2021 14:30
  - Check Recurrent and go to Recurrence tab
  - Select repeat every 1 weeks
  - Select Monday

Issue:

  Wrong date for next occurrences (first occurrence is 09/06 instead
  of 10/04).

Cause:

  Calculation based on today date.

Solution:

  Calculate next occurrences based on planned_start_date if set.

opw-2628777

closes odoo/odoo#75793

Related: odoo/enterprise#20529
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>

Steps to reproduce the bug:
- Go to Accounting
- Create an invoice:
    - select a `invoice_payment_term_id`
    - Add product on “account.move.live”
- Save and duplicate it.

Problem:
The `invoice_payment_term_id` field will be duplicated on the second invoice, but not the `invoice_date_due` field

Solution:
The `invoice_date_due` field is set in the `_recompute_payment_terms_lines()` function when adding an `account.move.line`.
As in the duplicate invoice we also have an `account.move.line` we can therefore call this function so that the field is set
https://github.com/odoo/odoo/blob/14.0/addons/account/models/account_move.py#L1043



opw- 2628333

closes odoo/odoo#75476

Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

Steps to reproduce:
- create a carrier with a fixed price (1) in the backend
- go to website
- add a product (2) in cart, process checkout and arrive in the payment page
- select the carrier
- the total price is now (1) + (2) which is correct
- in a separate browser tab, add another product (3) in cart, then click on
  continue shopping
- go back to previous browser tab and click on Pay Now
- the total price is now (2) + (3) which is not correct, the delivery cost is
  missing (it was removed due to second tab operations)

closes odoo/odoo#65474

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

Rounding in purchase order is 'UP' which is causing issue when doing
receipt in a different uom than the purchase. Rounding should be
'HALF-UP'

Added test in purchase and sales to ensure this issue is detected in the
 future.

closes odoo/odoo#75975

X-original-commit: 3f6f5868
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

_retrieve_{partner,product,tax} methods were not taking into account a
scope of a company, and methods like _import_ubl or _import_facturx
could end up on creating an invoice with a company mismatch between the
company of the journal and the company of the partner, product or tax.

With this commit, these methods will consider the allowed_company_ids
context value, and calling code should set it to an acceptable value.

OPW-2560795

closes odoo/odoo#75738

Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

a9a46cf0 introduced methods _retrieve_{partner,product,tax} but they
were not used in 14.0, whereas they are used from saas-14.1.

This commit changes the account_edi_facturx and _ubl modules so that
they make use of these methods.

Part-of: odoo/odoo#75738

Steps to follow

- Install web_dashboard,website_sale
- Go to the eCommerce Dashboard
- Click on Favorites
- Click on Add to my dashboard
- Go to the Dashboard app
- Click on orders
-> A traceback occurs

Cause of the issue

`this.subscriptions.update` is undefined

opw-2630849

closes odoo/odoo#75719

Signed-off-by: Hubert Van De Walle <hubvd@users.noreply.github.com>