- Open session with cash control
- Set 300 €
- Close session
- Add Cash 50€
- Close session
- Set end Cash at 350 €

--> It raise an error

closes odoo/odoo#78780

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

Stock.location is ordered by "complete_name" which is possible to be the
same (i.e. default production locations for different companies). This
may result non-deterministic order. Add "id" to avoid it.

closes odoo/odoo#79169

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

If a work center is used in any routing, a warning will be displayed when it will be archived

opw-2658596

closes odoo/odoo#79087

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

In case you use products with variants or internal references, display_name is more specific than name.

closes odoo/odoo#79130

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

In last added migration script in https://github.com/odoo/odoo/commit/b40216a8ae8fefd03311b2884e7b83644baac0a1

, the code assumes the chart of account of l10n_es is installed. But happens that you may have installed several l10n_* modules, including l10n_es, but not having the chart of l10n_es installed (you have installed the chart of another module).

In this case, then the update crashes because tax_ids is None and tuple(tax_ids) crashes!

closes odoo/odoo#79024

X-original-commit: f5b21797
Signed-off-by: Olivier Colson <oco@odoo.com>

closes odoo/odoo#74896

closes odoo/odoo#78468

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

Steps to reproduce:
1. Create Manufacturing Order with quantity >1 of Serial Tracked product
2. Press Mark done. (One Product will be immediated produced with a new
   SN auto-created)
3. Create Backorder
4. Press Mark done on the backorder

Expected Result:
Backorder will also be able to immediate produce and auto-create a new SN

Actual Result:
Usererror because env is still referring to original MO and tries to
produce the same SN again.

closes odoo/odoo#79123

Fixes: odoo/odoo#78134
Signed-off-by: Arnold Moyaux <arm@odoo.com>

Currently, hovering on the tooltip displays some content out of
the viewport. It happens because tooltip content div requires
270px width to display the text and the distance between the
tour indicator and viewport is less than 270px

so this commit fixes the issue by changing the position of the tooltip
indicator from left to the top so that the tooltip indicator displays
top of the element and hovering on it displays the full content

TaskID-2667140

closes odoo/odoo#78529

Related: odoo/enterprise#21914
Signed-off-by: Laurent Smet <las@openerp.com>

This commit fixes the 'You need to supply a Lot/Serial Number...' message
when validating a receipt with backorder for subcontracted tracked products.

closes odoo/odoo#78062

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

- The batch version of get_metadata won't work correctly for the xmlid
returns due to the limit=1 (cause by
718b0f8b ). Fix the
previous issue by reversing the order and without limit.
- The read should be read with the correct user.

closes odoo/odoo#79076

X-original-commit: 29a53f19
Signed-off-by: Rémy Voet <ryv@odoo.com>

Suppose an automated AVCO product category. When confirming an invoice,
if the associated product was a kit and if its BoM has changed during
the process, a traceback can occur.

To reproduce the issue:
(Need sale_management)
1. Create a product category PC:
    - Costing Method: AVCO
    - Inventory Valuation: Automated
2. Create 3 products P1, P2, P3:
    - Product Type: Storable
    - Category: PC
3. Update P3's quantity > 0
4. Create two bills of materials:
    - BOM01:
        - Product: P1
        - BoM Type: Kit
        - Components: 1 x P2
    - BOM02:
        - Product: P2
        - BoM Type: Kit
        - Components: 1 x P3
5. Create a sale order SO with 1 x P1
6. Confirm SO and process the delivery
7. Edit BOM02:
    - BoM Type: Manufacture
8. On SO, create the invoice INV
9. Confirm INV

Error: an Odoo Server Error is displayed with a traceback: "[...] in
_compute_average_price, bom_line_data = bom_lines[bom_line] [...]
KeyError: mrp.bom.line(19,)"

On step 7, when changing the BoM type, a new BoM line is created.
Therefore, in `_compute_average_price`, the BoM associated to the move
(i.e., `bom_line`) is not one of the lines in `bom_lines` (i.e., the new
BoM lines). There is already a check in case the line has been deleted,
but not if it has been changed.

OPW-2610685

closes odoo/odoo#78917

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

We create the document types data with a csv file, but the active field
should be not updatable so the users could active or inactive records.

closes odoo/odoo#78576

X-original-commit: a7ea6f21
Signed-off-by: Josse Colpaert <jco@openerp.com>

Fix a small logic bug which made it so draft outs would only show only
if there were also draft ins.

closes odoo/odoo#79037

Fixes: odoo/odoo#78872
Signed-off-by: Arnold Moyaux <arm@odoo.com>

commit 96b56ea3 fix the link between SO <-> MO in manufacture 3 steps
but break it on other configuration

It happens because without `store after manufacturing` the procurement
group is not copied and used on the MO. And the stat button search on
procurement group with a MO and a SO on it. Before it was searching
on `stock_move.created_production_id` and thus was able to find the MO.

This commit do a mix of the 2 solutions. It search for procurement group
linked to SO and MO + created_production_id to be sure to find all the
MO related to a SO

opw-2645042

closes odoo/odoo#79015

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

The number that was there before was a TFN, not an ABN because of
confusion between those two tax numbers.
See
https://github.com/arthurdejong/python-stdnum/commit/cc3a970e893ebe6635982bcd49c48e6549cb5ac3
https://github.com/odoo/odoo/commit/a72f7222c9f5987a20461be9c837e3de73801ff7



closes odoo/odoo#78894

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

closes odoo/odoo#78883

X-original-commit: 83bb18e4
Signed-off-by: Olivier Colson <oco@odoo.com>

Fix https://github.com/odoo/odoo/commit/b40216a8ae8fefd03311b2884e7b83644baac0a1

 was merged though partially ready.

closes odoo/odoo#79005

X-original-commit: 880c32f9
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: Olivier Colson <oco@odoo.com>

Issue:
Our functionality for merging PDFs from multiple vendor bills relies on PyPDF2. It is well-known that PyPDF2 is sometimes unable to manipulate even perfectly normal PDFs. To provide a helpful error message to the user when this happens (i.e. give them the names of the vendor bills corresponding to the offending pdfs), the `_get_unreadeable_pdfs()` function is called right before we try to merge the PDFs in `_merge_pdfs`. This function is meant to identify the offending PDFs and provide them to the user.
However, _get_unreadable_pdfs did not notice the problem with 3 of my customer's pdfs, because the error was only triggered once the PdfFileWriter.write function was called in _merge_pdfs. This function, however, is not called in _get_unreadable_pdfs, therefore, it did not notice that anything was wrong.

Fix:
- Change _get_unreadable_pdfs so that it also makes a call to PdfFileWriter.write
- As soon as PdfFileWriter.write fails once, it will continue failing when we append more PDF streams to the PdfFileWriter. I therefore suggest initialising a different PdfFileWriter at each iteration of the for loop in order for an offending PDF to not cause a false positive on subsequent PDFs.

closes odoo/odoo#78955

X-original-commit: 0b4efd37
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>

Reproduce :
(With timezone GMT+3)
- Create any record R1 with previous day's date and time after 21:00.
- Create any record R2 with today's date and time after 21:00.
- Create a filter to show all todays records (Date is between "<TODAY'S DATE> 00:00:00 and <TODAY'S DATE> 23:59:59".

Result :
  Even though R1 is in yesterday's date, it will show in the list.
  R2 will not show in this list.

Explanation :
  This behaviour has been observed in several modules, for any timezone but UTC & only with custom filters default datetime values.
  The search was applied on [datetime(UTC) + 2 * offset] because the timezone wasn't correctly set.

Solution :
  Timezone is now correctly set on default datetime values.

closes odoo/odoo#75663

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

A related field copies the attributes from its target field, except for
the attributes defined on the related field itself.  The implementation
of this feature was not working properly for attributes with a truthy
default value.

closes odoo/odoo#78687

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

It may happen that there is a property defined on some field that is not
the default property, but rather the property associated to a record.
For example
```
=> select id,name,company_id,fields_id,value_reference,res_id from ir_property where name like '%property_stock_inventory%'
+------+--------------------------+--------------+-------------+-------------------+----------------------+
| id   | name                     | company_id   | fields_id   | value_reference   | res_id               |
|------+--------------------------+--------------+-------------+-------------------+----------------------|
| 528  | property_stock_inventory | 1            | 4665        | <null>            | product.template,752 |
| 6    | property_stock_inventory | <null>       | 4665        | stock.location,5  | <null>               |
+------+--------------------------+--------------+-------------+-------------------+----------------------+
```
In this case the property with id=528 is not a default property since
res_id is not NULL. Alternatively the property id=6 is a default one.

The issue here is that when searching for the missing locations we do
not filter out the properties with res_id not NULL, thus we may get that
a company has the location define while in fact it doesn't. Following
the example above, this means that we incorrectly get property id=528 as
the one defining the location for the company id=1 here:
https://github.com/odoo/odoo/blob/c5c47da2e96fd5e37030c70d6bb1bae4c4047fa8/addons/stock/models/res_company.py#L107
This not only prevents the creation of the correct default property but
also the default locations
https://github.com/odoo/odoo/blob/c5c47da2e96fd5e37030c70d6bb1bae4c4047fa8/addons/stock/models/res_company.py#L36-L51



On this patch we fix the domain search for default property. This allows
for the correct creation of the default locations and associated
properties.

This issue was observed during upgrade 40921, where it prevents the
upgrade to 15.0

closes odoo/odoo#78949

X-original-commit: 17e74b48
Signed-off-by: Arnold Moyaux <arm@odoo.com>

The "Save" / "Cancel" buttons were wrongly showing on the "My Profile"
page.

closes odoo/odoo#78820

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

Selection of multiple companies to view multi-company data was added
in v13, but at the time there was no way to have reports correctly
take into account currency rates when also working with multi-currency.
v14 onwards is able to correctly apply the currency rates, therefore we
fix the purchase report to do so.

Steps to reproduce:
1. Start with existing demo data + add a new company with currency = EUR
2. Activate multi-currencies + set a currency rate (not 1) for Euro to $
3. Open Purchase Report (Purchase > Reporting > Dashboard)
4. Activate demo company + new EUR company
5. Switch between USD and EUR company as selected company

Expected result:
  Dashboard monetary quantities switch between $ and EUR, i.e. both the
  amount changes according to current exchange rate and symbol.

Actual result:
  Currency symbol changes, but amount stays the same.

closes odoo/odoo#75651

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

The end datetime is not timezoned in _adjust_to_calendar before defining the search_range and using the _get_closest_work_time method.
Since _get_closest_work_time will timezone the timestamp received to start searching, the search interval needs to refer to the same end timestamp to avoid erratic behaviors.

Task-2628876

closes odoo/odoo#76374

Related: odoo/enterprise#20783
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Same fixes for the purchase scope

1) Do not overwrite lines description if the line was not modified

2) Correctly recompute prices/sellers on quantity change.

When no new line was added to the PO through the matrix, the
prices/sellers were not recomputed, even if the qty was modified for
some products.

closes odoo/odoo#78902

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

1) Do not overwrite lines description if the line was not modified

Fixes #78833

2) Correctly recompute prices on quantity change.

When no new line was added to the SO through the matrix, the prices were 
not recomputed, even if the qty was modified for some products.

The prices have to be recomputed in this case since pricelist provide 
rules based on minimum qty.

Part-of: odoo/odoo#78902

Seems like depending the pillow version, the output image size could differ
from one or two bytes. Now we check the expected size with a tolerance of
+/- 1 byte.

closes odoo/odoo#78935

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

Most uses (correct ones) of the `partner` context key content expect a `res.partner` recordset as `partner` context value.
This value is extracted during the pricelist price computation (but not used anyway...).

But in one case, fixed by the current commit, a `res.partner` id is placed in the context, as `partner` value.  In some cases, this may trigger "Comparing Apple and Oranges" errors, since `with_context` calls returns a new or existing environment, verifying whether an environment with the same values (user, context, ...) exists.
During this comparison, the new context, with an id (int) as `partner` value, is compared with existing contexts, potentially including some with a recordset on the same key.  Such a comparison fails on the lowest `__eq__` level, raising "Comparing apples with oranges" error.

This commit fixes this case, by making sure the value put in the `partner` context value is always a recordset, and not an id.

closes odoo/odoo#78936

Note: In the future, this context key should be dropped because it's still a bad practice to put recordsets in the context.
Forward-port-of: odoo/odoo#78276
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

WO are released in confirmed state, but the help message says that they are released in draft.

opw-2609040

closes odoo/odoo#78890

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

Steps to reproduce the bug:
- install mrp_workorder
- Create a new work center which will work every day from 8:00-9:00
- Create a BOM with component and operation, which takes 24 minutes in your work center
- Create 4 MO for this bom
- Set manually scheduled date > 1 MO should have a different date than others, e.g:
    - 3 MO → 01/dec/2021 08:00
    - 1 MO → 02/dec/2021 08:00
- Plan the MO which has different date than others

The ```planned_end_date``` is not calculated correctly

Current behavior before PR:
MO_1 : 01/dec/2021 08:00 → 01/dec/2021 08:24
MO_2 : 01/dec/2021 08:24 → 01/dec/2021 08:48
MO_3 : 02/dec/2021 08:00 → 02/dec/2021 08:24
MO_4 : 02/dec/2021 08:24 → 02/dec/2021 08:24

Problem
The MO_4 should only last 20 minutes, while it lasts 23 hours and 48 minutes.

opw-2648065

closes odoo/odoo#78377

Related: odoo/enterprise#21701
Signed-off-by: Rémy Voet <ryv@odoo.com>

Some of the support scripts use xml-rpc calls to work
on pos.session on Saas or SH databases
(especially when needed to upload lot of offline orders
in smaller batches)
These scripts should be allowed to close any rescue session
created during this process programmatically via xml-rpc.

Our xml-rpc protocol does not allow to call function that
return nothing

closes odoo/odoo#78909

X-original-commit: 834bed30
Signed-off-by: Masereel Pierre <pim@odoo.com>

Issue: When returning a product sold that is only made of kits and
validating the return, the delivered quantities of the sales order was
set back to the full amount delivered

Steps to reproduce :
  1) Install MRP and Sales
  2) Create a BoM Kit for a new product [Nested Kit] that has one or
    more consumable or storable product as component
  3) Create a BoM Kit for a new product [Main Kit] that has
    [Nested Kit] as component
  4) Create a SO for [Main Kit], confirm, validate delivery
  5) Check SO, 1 product is delivered (correct)
  6) Go back to the Delivery, create a return for the delivery
    (don't validate)
  7) Check SO, 0 product is delivered (correct)
  8) Now validate the return for the delivery
  -> Check SO, 1 product is delivered (bug)

Why is that a bug:
 Since the Main Kit was returned, the delivered should be 0 and not
 the full amount initially delivered. It was set back to 1 because we
 didn't look at the type of picking, when computing the quantity
 delivered, the fall back considered that if all the moves were done,
 everything was delivered, but it is the opposite when returning

opw-2542337

closes odoo/odoo#78838

X-original-commit: e90452bf
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>

Purpose
=======
Fix guest users receiving confirmation emails for events by "Public User".

Specifications
==============
Confirmation emails for events are sent by:

- Organizer (if set)
- Company email (if set)
- The users's email
- Odoo bot otherwise

Task-2657588

closes odoo/odoo#78849

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

(Backport : fbf76c1f)

Expected behavior : Quantities are displayed in the same way on the delivery note regardless the stock picking stage.

Current behavior : Quantities aren't displayed in the same way on the delivery note depending on the stock picking stage. (e.g. `2.00 Units` units when picking is in `Waiting` stage but `2.0 Units` when picking is in `Done` stage)

Steps to reproduce the error :
- Create a RFQ with few units of a Storable Product (e.g. 2 units)
- Go to the Receipt and print the Delivery Slip and look at the quantities printed (e.g. 2.00)
- Validate the Receipt and print the Delivery Slip again, quantities printed have changed (e.g. 2.0)

opw-2578120

closes odoo/odoo#78815

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

Expected behavior : The order button should go green and active when you 'unskipped' an orderline

Current behavior : The order button doesn't go green and can't be clicked when an orderline is 'unskipped'

Steps to reproduce the error :
First of all, you need to setup a PoS Restaurant with these options :
~ Bar/Restaurant
~ Enable `Table Management`
~ Enable and setup `Order Printer` with IP Address and choose Categories to be printed on.

1. Open a restaurant session
2. Pick a table
3. Select a product and put it on hold
4. Select the **same** product and order it
5. 'Unskipped' the product from step 3

Order button should be green and active but is unactive so the order can't be sent

Previously, the condition was only based on the product_id so error occurs when multiline of the same product are handled

opw-2557518

closes odoo/odoo#78829

X-original-commit: 8159e5ac
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

Mod 303's grid 61 is now divided in 4 new lines: 120, 122, 123 and 124. Grid 61 isn't used anymore. This takes effect starting July 1st 2021; previous periods are unaffected.

Doc:

https://www.agenciatributaria.es/AEAT.internet/Inicio/Ayuda/Disenos_de_registro/Modelos_300_al_399/Modelos_300_al_399.shtml

https://iranon.es/modelo-303-cambios-a-partir-del-3t-y-mensual-de-julio-de-2021/



OPW 2662476

closes odoo/odoo#78651

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

quotation_description on the sale order is copied from the
product template, where it already is sanitize_attributes=False,
and it has to stay like that because otherwise widgets like
"tab" or "accordion" cannot be rendered correctly.

This is also linked to a bug in the ORM where the _related_attrs
weren't copied correctly.

Related ORM PR: https://github.com/odoo/odoo/pull/78687
Ticket link: https://www.odoo.com/web#id=2487749&model=project.task



opw-2487749

closes odoo/odoo#78818

X-original-commit: ee90f6bc
Signed-off-by: Paolo Gatti <lordkrandel@users.noreply.github.com>

Expected behavior : The log note sent when received quantity is updated should take into account the quantity already received.

Current behavior : The log note sent doesn't take into account the quantity already received for a 'stock_moves'. So it always displays `Received Quantity: 0.0 -> quantity in stock` instead of `Received Quantity: quantity already received -> quantity in stock`

Steps to reproduce the error :
- Create a RFQ with few units of a Storable Product (e.g. 5 units)
- Partially validate the receipt and create a backorder (e.g. 3 units)
- Validate the backorder (e.g. 2 units)

Log notes should be :
`Received Quantity: 0.0 -> 3.0`
`Received Quantity: 3.0 -> 5.0`

But are :
`Received Quantity: 0.0 -> 3.0`
`Received Quantity: 0.0 -> 5.0`

The value is always equal to 0.0 because `qty_received_method == 'stock_moves'` so `line.qty_received` is overridden by 0.0 in parent `_compute_qty_received` even though its value is already set to 0.0 (default) or to the quantity already received

opw-2600221
opw-2613116

closes odoo/odoo#78286

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

Due to floating point limitation, the quantities displayed in the
forecasted report should be formatted to ensure the rounding.

Issue example:
(Need stock)
1. Create a storable product P
2. Update its quantity to 7.1
3. Consult the Forecasted Report

Error:
Quantities are "7.1000000000000005 Units". In this case, the
floating-point issue comes from the method `float_round()`

Another example:
(Need purchase_stock)
1. Create a storable product P
2. Update its quantity to 0.1
3. Create a PO with 0.2 x P
4. Consult the Forecasted Report

Error:
The "Forecasted + Pending" quantity is 0.30000000000000004 Units. This
field is directly computed while rendering the report, it's the sum of
0.1 and 0.2 which, in python, results in 0.30000000000000004
(floating-point issue)

Since the rounding of these quantities are actually based on the decimal
precision of the UoM, this commit may slightly change the report.
Suppose the generic precision is .001 and the precision of "Units" is
0.01: if the quantity is 12.34, one zero will be added in the report:
12.340. However, these unnecessary zeros do not change the information
that is initially displayed. Moreover, the UoM precision can not be
greater than the generic precision, so we will never lose a part of the
quantity to display.

OPW-2611892

closes odoo/odoo#78773

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