product variable used in the rounding precision come from the upper
loop and won't work for all the quantites.

opw-3229080

closes odoo/odoo#121247

X-original-commit: ea923a08
Signed-off-by: Tiffany Chang <tic@odoo.com>

When an orderpoint triggers a procurement for a product and the system does not find the procurement route, it schedules an activity remembering what was the error.

If a normal user without admin access rights, makes an action that triggers the orderpoints, like confirming a MO, the activity schedule is not creating due to an access error on 'write' operation to a Product Template.

So, all activity schedules triggered from an orderpoint should be created without checking access rights.

closes odoo/odoo#118300

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

Steps to reproduce:
- install sales, MPS, and purchase
- Create a product P with Manufacturing route and
component cp with Buy route
- Make sure that components cp are not enough in stock
and the system runs reorder rule for it.
- Create a Sales order for product P and confirm
- run scheduler > the system will create a reordering rule
for both products ( product P and its child component CP).
- Now delete the Reordering rule for product P and change its BoM to Kit
- Run the scheduler again
- Try accessing the Replenishment

Bug:
An error message "A product with a kit-type bill of materials
can not have a reordering rule."

Fix:
back porting this fix [1] (prevent creating an order point for
manufactured products of type kit)

opw-2998740

[1]:https://github.com/odoo/odoo/pull/104366



closes odoo/odoo#107231

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

To reproduce the issue:
1. Ensure you have an orderpoint in automatic that will be processed by the scheduler
2. Allow a worker to run the scheduler with use_new_cursor=True
3. After orderpoints are searched in procurement.group._run_scheduler_tasks
   and before the orderpoint is processed in stock.warehouse.orderpoint._procure_orderpoint_confirm,
   delete the orderpoint through another worker

Error: A CacheMiss error will be raised due to the access to orderpoint.qty_to_order
in _procure_orderpoint_confirm, what will leave open the transaction from the new cursor
declared in the same function.

After a while HTTP workers will become unavailable as their own transactions will wait for the lock
of the open transaction to be lifted, what won't happen before said transaction is closed.

OPW-3121598

closes odoo/odoo#110543

X-original-commit: 4b2af1e1
Signed-off-by: Christophe Simonis <chs@odoo.com>

Currently if you require internal transit pickings between warehouse,
it's not possible to use security days in order to plan them and
receive products on time (e.g the second warehouse need times to
manufacture them).

Also the deadline are impacted by security days, so it's hard to
do at the same time replenish on order an use the orderpoints.
(either you see them late in orderpoints or they are plan way to
early in replenish on order process)

To avoid this kind of issue this PR introduces a visibility days
global on the orderpoint. It's call `stock.visibility_days`.
It will add the number of days in the orderpoint forecast date but
it doesn't impact the documents (PO, MO) planned dates.

It could for example always show the quantity in 1 years if people
don't need the just in time feature and don't care to store for a
long period of time.

closes odoo/odoo#110248

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

First correction: force a simple order to `read_group` in order to avoid
useless joints on table product_template and ir_translation when the
grouping key is a Many2One.

Second correction: add an index on workorder's `state` field. The
get_conflicted_workorder_ids() method search for ready workorders that
are in conflict relate to their planning. The state value is searched to
many times to not index it

closes odoo/odoo#106436

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

savepoint do a flush that throw the current context and then recompute
the stored field (with a random matching context from the transaction).
In the case of qty_to_order, it will call qty_forecast and then
_compute_quantities on product.product.

Currently it will call _compute_quantities with a mix of self.env.context
(from the transaction) and a context generated from the orderpoint (with
deterministic data). But sometimes in the context took from the
transaction it could remain some other key used by _compute_quantities
(e.g. warehouse_id). Since qty_to_order doens't depends from context
it should not use self.env.context and only use the deterministic
context from the stock.orderpoint

closes odoo/odoo#100131

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

The below line raises a KeyError when `warehouse` refers to an archived
warehouse.
https://github.com/odoo/odoo/blob/01cc43b0578ecc9d1fed37a12b2468ffc9d4aedd/addons/stock/models/stock_orderpoint.py#L396

The reason is that the SQL view created on
https://github.com/odoo/odoo/blob/01cc43b0578ecc9d1fed37a12b2468ffc9d4aedd/addons/stock/report/report_stock_quantity.py#L28-L37


doesn't take into account whether the warehouses are archived or not.

The solution proposed here is to fetch all warehouses to ensure the
lookup doesn't fail. Alternatively the view could be updated but that
will be a bigger change.

This issue was detected during the upgrade 226754

closes odoo/odoo#97222

X-original-commit: aaa7fb8f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>

On the commit 69dcdd41, the order='create_date desc'
 was removed and the way of getting the MO for the notification changed. Now, the context is used, it should be written_after instead of written_date.
In addition, the now declaration should be at the beginning of the method action_replenish.
(The MO created is correct, only the notification is wrong)

Should be forwarded
OPW-2877457

closes odoo/odoo#96085

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

On the commit 69dcdd41, the order='create_date desc'
 was removed and the way of getting the MO for the notification changed. Now, the context is used, it should be written_after instead of written_date.
(The MO created is correct, only the notification is wrong)

OPW-2877457

closes odoo/odoo#96821

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

Updating the scheduled date of a delivery doesn't update the quantity to
order of an orderpoint

To reproduce the issue:
(Need purchase)
1. Create a storable product P with a seller
2. Create and confirm a planned delivery D with 1 x P
3. Open the replenishment page
    - There should be a line for P (Forecast: -1, To Order: 1)
4. Edit D and postpone the scheduled date
5. Go back to replenishment page

Error: The line is still present, its forecast qty is correct (0) but
the quantity to order is still 1 (instead of 0)

`qty_to_order` is a stored field, so when loading the replenishment
page, its compute method is not called. Moreover, even though
`qty_to_order` depends on `qty_forecast` and the compute method of
`qty_forecast` is called, it still won't trigger the compute:
when setting the value of `qty_forecast` from its compute method, it
will lead to:
https://github.com/odoo/odoo/blob/b54f78de307543efcea934206806f361eaac811a/odoo/fields.py#L1106-L1109


So, as shown and explained, we bypass the `write` of `BaseModel` and
skip the business logic and the recomputations

The compute of `qty_to_order` should actually be triggered earlier: when
we edit the scheduled date (step 4). That's the reason why this commit
adds a dependency to the compute of `qty_forecast`: it makes more sense
and becomes an implicit dependency of `qty_to_order` -> update the
scheduled date will trigger the compute of `qty_to_order`

OPW-2868167

closes odoo/odoo#94196

X-original-commit: 1727782d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

Avoid leaks in case of exception.

closes odoo/odoo#93866

X-original-commit: b0e22ba19d01f87980ee7b72d6c78998d92bd8f2
Signed-off-by: Christophe Simonis <chs@odoo.com>

following commit 55398263
Introduce a new param to fix a notification issue. However
we could use the context instead of a new parameter in order
to avoid breaking the customisation.

Linked to PR #88303 discussion

closes odoo/odoo#92305

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

When clicking order now on a replenishment line (orderpoint) for a manufacture or WH resupply route, it will sometimes show a notification for a purchase order that was created earlier instead of the correct one.

closes odoo/odoo#91320

X-original-commit: 55398263
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>

Steps to reproduce:
- Create two extra warehouses (B and C):
 * Warehouse B: Resupply from San Francisco
 * Warehouse C: Resupply from San Francisco
- Create a new Product:
 * Storable
 * Inventory > Routes: select only Warehouse B and Warehouse C
- Create a new Move:
 * From WHC to a Customer
 * Confirm the order

Issue:
In replenishment, the defined prefered route will be Warehouse B

Cause:
When the replenishment view is loaded, in
https://github.com/odoo/odoo/blob/5757502a79c920e1aa4c7ca1c581c533907ce674/addons/stock/models/stock_orderpoint.py#L427


The preferred route (route_id) is defined as the first element of the routes defined for the produc which is wrong.

Solution:
Filter the route_ids by selecting the route for which the supplied warehouse is equal to the warehouse selected for the orderpoint.

Note:
The test in "test_bom" has been modified because it was using the wrong flow (a route should have been set by default)
opw-2815462

closes odoo/odoo#89739

X-original-commit: b5bd03f9
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>

Remove the Purchase Security Lead Time from the computing of the
purchase order's picking deadline to better reflect that the shipment is
actually meant to arrive earlier than date + security lead time.

Also makes sure that receipts and subsequent pickings (multi-step
reception) are planned the earliest possible, not taking the purchase
security lead time into account.

Task-2656397

Part-of: odoo/odoo#78199

Fix the inconsistency of product_{min,max}_qty in orderpoint. Both have
different tooltip saying that the reordering rule would trigger if :
- min: forecasted_qty <= product_min_qty
- max: forecasted_qty < product_min_qty

As the tooltip of the product_max_qty is in fact correct, we adapt the
tooltip of the product_min_qty to match the reality.

Task-2656397

Part-of: odoo/odoo#78199

The logs of the scheduler wasn't correct ( 4467734b ):
- The number of object process wasn't correct for the last batch
- Fix Spelling  of "commited"

Also, we commit every 1000 moves assignation instead of 100.
(Because the prefetch already prefetch by 1000 and to benefit
futher the batch optimisation of _action_assign).

Part-of: odoo/odoo#75041

When a document (SO/MO) create a demand and this demand is directly
refill by an orderpoint, then write the source document that triggered
the orderpoint in addition in the origin field.

The purpose is to have an easy base tracking configuration even if
the priority and schedule date (and the final customer) could change
afterward (origin field still editable)

Part-of: odoo/odoo#75144

the deleted commit is not needed since it's already called in
`_procure_orderpoint_confirm`.

The logs are usefull to check whether we have progress on repeating the
scheduler that gives timeout error.

closes odoo/odoo#75146

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

mrp - when a MO is generated from replenishment report, a log note is added
to chatter with the link of replenishment report, as this report got deleted
when to to qty is 0.0 then link dost not work. Hence added the simple text
for Relenishment report.

purchase_stock - When click on the order once button of replenishment report,
if vendor is not added on product then, added a new wizard with functionality
to directly jump on the edit product.

Added log note to the PO if po lines are generated through the Replenishment
report.

TaskId - 2427738

[IMP] stock: split method to create new or unlink unused OP

As, server action was added to the Replenishment menu, unless
until user clicks on the menu, new order point will not get
generate. Hence splitted the method and added to auto vaccum for
this.

TaskId - 2427738

closes odoo/odoo#66130

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

Fine tuning of https://github.com/odoo/odoo/commit/c7b32e0795bc1573d81563f31a75fa44c64b39c2



closes odoo/odoo#74361

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

Currently the replenishment report look for forecasted quantity of
product today. It means that for a product if the delivery is planned
for today the forecast will be -1, at j-1 it will be 0. However for the
majority of use case, products take days to order and arrive.

Example:
- Product A, purchase delivery time 5 days.
- You are the 01-01-2021 and create a SO for 10-01-2021
Currently:
- Product will appear in the replenishment report the 10-01-2021 and
you will receive it the 15-01-2021. So you are late to deliver your
customer.
Desired behavior:
- Product appear in the replenishment report the 05-01-2021 and if you
order it directly you will receive it the 10-01-2021.

If you want to have more time to deliver than one day, security lead
time are there for it.

However the usecase like:
Product arrive in 2 months and you receive it in 3 days, the product won't
appear in the replenish report anymore since the forecast in 3months is
0

It could happens that more product are missing in 3 months than today,
so the system could have more delivery lead times and forecast at date
to compute -> be slower. In that case a parameter could be
added to skip the delivery times computation for each product/warehouse
and just display the forecast in 3 months and let user compute their
schedule themself.

closes odoo/odoo#73737

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

task-2558097

closes odoo/odoo#71870

Related: odoo/upgrade#2538
Related: odoo/enterprise#18849
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

Infobox to help the user with the replenishment. Allow those actions:
- See the different supplier with their lead time, price and quantity
- Be able to select a supplier and set it on the orderpoint
⁻ See the last delivery by mmonth for the product
- Last purchase date for each supplier

Technicaly it use a wizard and a fields char with JSON used by
a widget to display a static template. Also it creates directly
the wizard in backend instead of just let the view manage the new
object since we need a button on a one2many and if the records do
not have an id, it's not possilbe to use it.

closes odoo/odoo#72039

Task: 2519761
Related: odoo/upgrade#2596
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

A security has been added to avoid an infinite loop due to custom
code if the failing orderpoints were not correctly return in order
to exclude them from the set to retry.

However after a first batch if some orderpoints were correctly exclude
orderpoints_exceptions will not be empty and during the second iteration
failed_orderpoints will be always filled from exceptions of previous
iterations and the infinite loop will not be detected.

opw-2525893

closes odoo/odoo#71938

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

Forward port of #70351

closes odoo/odoo#70557

Related: odoo/enterprise#18215
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

Usecase to reproduce:
- create a product with 0 stock
- Sale order 500 units
- a RFQ is created for 500 units
- in replenishments, you have 0 units to order, OK
- RFQ --> confirm PO
- in replenishments, now the quantity to order is 500
--> should still be 0, it leads to confusions

It happens because the replenish action check the missing
quantity for today. It result by -500 units since the delivery
is planned for the next day (default supplier lead days = 1).
But since the orderpoint exist, the quantity forecasted is
already computed correctly with the right lead time.

But the action will remove the 500 missing today from the
quantity forecasted (The idea is to add the missing quantity on
the main location. e.g. I have
-10 units in WH/Stock/Shelf1
-20 units in WH/Stock
The orderpoint will only look for its own location -> 20 to reorder
The replenishment report look by warehouse and not by location -> 30
missing. So 30 missing + 20 incomming -> 10 to add (by default on
WH/Stock)

The fix is to add a step when a product is missing then compute its
virtual available with lead days (to avoid missing confirmed moves
during the lead time).

opw-2456978

closes odoo/odoo#69527

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

This method is useless and it bypass the computation of some fields
(qty_available, virtual_available, incoming_qty, outgoing_qty). Then
this method is not cache-friendly, and we should use `read` instead.

task-2439019

closes odoo/odoo#66621

Related: odoo/enterprise#16584
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

To avoid multiple search of the get_warehouse for the same location
and extra SQL request (it happens a lot for complicate flow, e.g.
mrp_mps, replenishment report).
Translate it into a standard compute to use the cache of
the ORM for no-store compute field (`warehouse_id`) and put
some depends to be always correct (even if `warehouse_id` shouldn't
change in the same request).

task-2439019

If some RR is archived and where the a forecasted demand on the
warehouse location, it Replenishement will crash will due to the
SQL constraint. It happens because the archived RR aren't take in
account in `_get_orderpoint_action` and the method will try to
create a orderpoint with same product + location which
lead to trigger the SQL constraint `product_location_check`.

Also avoid filtered in for loop to improve performance and use the
read_group instead.

task-2439019

closes odoo/odoo#67936

X-original-commit: 6737feef
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>

The replenishement creation currently calculates the quantity to order
using a default multiple quantity of 1. In case of manufacturing route,
we want to calculate the multiple quantity according to the quantity
produced in the BoMs.

closes odoo/odoo#62766

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

When checking the replenishments, it sometimes creates a new reordering
rule for a product while another already exists.

To reproduce the error:
(Need purchase,sale_management)
1. Create a product P
	- Must be storable
	- In Purchase tab, add a vendor
2. Create a reordering rule for P
	- Trigger: Manual
	- Min: 0
	- Max: 0
3. Create+Confirm a SO with P
4. Go to Inventory > Operations > Replenishment
5. On P-product's line, click on "Order Once"
6. Confirm the generated RfQ
7. Repeat 3-4

Error: There are now two lines for P-product. A second reordering rule
has been automatically created but the first one does already the job.

OPW-2431780

closes odoo/odoo#65142

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

Avoid to filter in a loop and use a read_group instead to group by
product-warehouse outside.
Also remove costly useless code.

Performance gain
----------------
On a large database (120K stock move, 5k product) where
+- 700 manual orderpoints will be create during the open of the
replenishement report:
Before:
16.14 +- 0.16 sec of python. (SQL time is +- 14 sec)
After:
1.33 +- 0.91 sec of python. (SQL time ==)

task-2390516

X-original-commit: 569b45d5cb139825690a90189b7a360f3fa89815

`o.location_id.id == g['location_id']` =>
`Comparing apples and oranges: stock.location(243,) == (219 ...`
replace by the correct code and avoid warning.

task-2390516

X-original-commit: 461a3e737c4ffe048b738dd09f83571602324257

Configure a reorder rule and a restock route for a product A
Go to Inventory / Operations / Replenishment
Remove all filters, find product A and under column 'To Order' input a
quantity, then hit the button 'Order Once'

The user quantity will be overwritten by the '_compute_qty_to_order'.
This is a fine tuning of f5054446

opw-2375317

closes odoo/odoo#61952

X-original-commit: 0d4ab53b
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Courtesy of translators
Reexport .pot of modified modules

closes odoo/odoo#61010

X-original-commit: 62a18bdb
Related: odoo/enterprise#14489
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Create 3 items:

* FP
 ** manufactured from SFP
 ** reordering rule
 ** manufacture lead time 2 days
* SFP
 ** manufactured from CP
 ** reordering rule
 ** manufacture lead time 2 days
* CP
 ** buy from vendor
 ** reordering rule
 ** manufacture lead time 2 days

Create a sales quotation:
 * Product: FP
 * Delivery Date: +7 days from now
Save and confirm
Run scheduler.

No Manufacturing process will be started.
This occur because the reordering rule (orderpoint) check the
quantity needed at the current date + lead days, while the move
are being planned for the delivery date specified by
the user in the SO.
Moreover the quantities that depends on datetime.now() are not recomputed
so each scheduler run is failing to schedule new orders

opw-2366925

closes odoo/odoo#60993

X-original-commit: 06eaf867
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>

This commit adds a constraint on model stock.warehouse.orderpoint
(reordering rule) to ensure two orderpoint are not set on the same
product and on the same location. This is an issue as the replenishment
will be done multiple times in case of duplicated rules.

Task : 1939567

closes odoo/odoo#47909

Related: odoo/upgrade#1814
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

Use fa-area-chart instead of fa-info-circle

closes odoo/odoo#58117

X-original-commit: 1c83b63e
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>