Usecase to reproduce:
- 10 company having 10 000 moves in state 'confirmed', 'partially_available'
- Run scheduler manually (without cron)
It will takes a huge amount of time.
It happens because the run scheduler wizard will call run_scheduler
as sudo for each company (passing company as arg).
run_scheduler will try to assign move that could be reserved. However
the domain in order to search move do not include the company_id and
search for every company.
Following upper usecase:
Instead of running action_assign 10 times on 10 000 moves, it will
run action_assign 10 times on 100 000 moves.
Databases with multi companies and having a lot of stock will have a
scheduler speedup from this patch.
Thanks "Rémy Voet <ryv@odoo.com>" for finding this issue.
opw-2328707
closesodoo/odoo#61183
X-original-commit: a21f9876b5b9d01380d03d638deb48cd091f26e7
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
date_deadline of the stock move has been reviewed:
- Now, it represents the datetime when the operation must
be done to be in time for the uppest document (SO/PO/MO/RR).
- At the creation of stock move the date_deadline is computed in
the same way than the sheduled date expected that it is not include
security days (inverse the logic for PO).
- When we update the delivery date (or lead time) of SO (or PO).
The deadline of related stock move is updated and the delta is propagate
between origin and dest moves.
task-2324039
- The deadline of MO generated via procurements is calculated differently.
Now, it doesn't take anymore in account the manufacturing_lead
of the company (Security Lead Time of MO). The computation of planned date remains unchanged.
- The date_expected fields was duplicated with the date fields
except when the move was done. Merge both fields.
The only information lost is: we can't know what was the
scheduled date before processing move (`state` == done).
Indeed, the date becomes the actual move processing datetime.
- The `date` in `stock.picking` field contained the time of
(purchase) order `date_order` (`purchase.order`).
This field is was wrongly used in the kanban view where we
expected to see date_planned instead. Also, the `_order` used
this date instead of date_planned too.
- The `delay_alert` is activate independently of stock rules.
Then it is now activate in all case.
- Remove the auto-reschedulting process of stock move via
the stock rule (`propagate_date` and `propagate_date_minimum_delta`).
Replace it by a automatic deadline date (`date_deadline`) propagation.
The deadline is the promise done to/by vendor/client (SO/PO)
then it is a readonly fields on picking/move and MO.
- Now the Scheduled date (`date`) of stock move is never propagate
and it is only related to the Scheduled date of
related document (MO or picking).
- Now when a move is created from procurement (sale),
`date_planned` = `date_deadline` - `security_lead`.
- The `delivery_date` of sale is no editable after confirmation
and propagate as the deadline to related stock move linked to order_line
- Adapt filter and decoration of MO and picking.
- Because we are the client in case of purchase (PO), the promise of vendor
can be not respected. Then we add the lead security to the deadline
(inverse the sale order logic) of PO picking (promise reciept date
+ security lead) to match with the replenishment.
task-2246665
Allow to "backorder" a production, meaning create another manufacturing
order with the quantity remaining to produce. We also use the
reservation of the first order on the next ones by using
`post_inventory` on the first one and moving the newly created stock
moves to the backorder.
We introduce a wizard similar to the one in stock.
Backorders have a sub-sequence.
Backorders are linked together through the procurement group.
We allow creating a backorder even if workorders are running by closing
them, the backorder will call `button_plan` and create its own.
task-2241471
- Create 2 companies C1 & C2
- Creae a product P
- In C1, set the routes as MTO + Buy, add a supplier
- In C2, add a BOM in kit for P
- Go back to C1 with C2 as an allowed company
- Create a SO for 1 unit of P, confirm
The PO for P is not created.
It occurs because the BOM of C2 is retrieved when running the
procurement, while it shouldn't be.
opw-2260945
closesodoo/odoo#51779
X-original-commit: 96b0dcf9e51f5a924e2cbf618c2ee5462cc1f03f
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Set the padding on the write for date. Modify the text to be consistent
with the manual and automatic orderpoint. Explains the min, max
and quantity to order mechanism.
closesodoo/odoo#48536
Task: 2161378
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
With this commit, Selection fields with `required=True` which are
extended via `selection_add` are given proper ondelete policies to
ensure the cleanup of records containing these extended options during
uninstall of the extending module.
This commit also cleans up leftover uninstall hooks that were being used
to handle the same set of problems prior to the ondelete mechanism being
implemented for Selection fields.
closesodoo/odoo#46325
Related: odoo/enterprise#9117
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Allow to propagate custom information to upper document. It could be
usefull in many buisness that do custom stuff for people
(t-shirt with user defined text, poster with own pictures...)
The customes values are pass throught procurements'values and are
display on MO or purchase order line.
Task: 1970476
Make it so documents auto-generated by other actions have Odoobot set as
the creator rather than the user triggering the action. This includes
the following documents:
1. Delivery (stock.picking) - generated by Sales orders (including MTO)
2. Purchase orders - generated by dropshipping, manual replenishment,
and run scheduler
3. Manufacturing orders - generated by made to order (MTO)
This is addresses specification 2 of overall usability improvement task.
Task: 2041853
Usecase to reproduce:
- Create a product MTO manufacture with a BoM
- Set produce delay as 1 day.
- Create a SO for the product and validate
The production order is created but with a duration of 1h.
It's due to commit 8944674d6d
It will use the moves finished date in order to determine the MO
finished date. However before this commit during _run_manufacture
the MO was created with a fix finished date and the move finished
date_expected was created with this date as date_expected.
Now the MO is created with the finished date, the inverse does
nothing since the finished moves do not exist yet.
In order to fix it, generate move_finished_ids use the product/company
manufacture delay. A first patch tried to rewrite date_planned_finished
after action_confirm. However it triggers the propagate date on
following moves.
closesodoo/odoo#44532
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Usecase to reproduce:
- Create a product with 10 days manufacture lead time
- Create a procurement in order to fullfill a need the 01/15
The MO start date is the 01/05 that's the expected values
The MO finished date is the 01/05, 1 h later than the start date
It happens due to commit 92aeaa47ff
This commit modified the wrong start date in order to take the
procurement date - manufacturing lead time. However it also
modified the finished date to 'the start date + 1h'. That returns
the problem to the opposite direction. Now the finished moves have
a wrong planning.
Fix it by using the production + company lead days when it's set
instead of 1h.
opw-2181962
X-original-commit: 6a5ce8de91d3ab2cb7f73127a6ee1c11578ccef9
In case of MTO (+buy) on products used in a MO,
add the link between the MO source and the PO generated.
Also add links between MO's when MTO+manufacturing.
task-1913392
closesodoo/odoo#43366
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Previously when the BoM on a product do not have components but only
services. Then during scheduler a log was posted on the product explaining
that components are required.
However since this process is possible in another usecase it should be
possible with procurement. The only difference is that procurements
confirm records in order to propagate. In this case since there is
no components and services are not propagate with procurements, it's
not needed to confirm the MO.
closesodoo/odoo#43133
Task: 2170845
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When the scheduler runs, each orderpoint will check the forecast stock
for an infinite time. As example, if we plan a receipt of 10 products in
4 months and need to deliver 5 products next month, procurement will not
be launched since we have a forecasted quantity of 5.
In order to improve it, the orderpoint will compute the total lead days
from rules, suppliers/production delays, security days,...
Those lead days will be added to today in order to know at which date
the forecast stock should be checked and trigger the replenish document
for today in order to be delivered at the correct date.
Task: 1849912
Currently orderpoint run one request at a time. However it's not
efficient since compute are some private methods could be executed
one time in batch instead of record by record.
The strategy in order to improve it is:
- Still cut the orderpoints in batch of 1000 (usefull when using a new
cursor with intermediate commit)
- For each batch of 1000, create a list of procurement values and run
them in batch (commit a2a6b099a4 for more info)
- Each time a procurement exception is raised, catch the failing
orderpoint and rollback to the state before run. Remove the failing
order point from the current set and run it again.
- run method try to catch a maximum errors by continuing to process even it
finds error in order to stack them. It would avoid to run the same set
again and again each time an error is raised.
test_orderpoint_1 took 975s before this patch and 100s after.
Task: 1849912
Currently when a procurement fail it will raise a user error.
Some function as run in stock_rule catch the errors and merge
them in a single error.
Also since commit a2a6b099a4 procurements
are executed in batch and in some cases, we would like to have more
information about the error. For example in orderpoint we would like to
know which orderpoint is responssible for which error.
It would also be possible to return an object with the details but
procurements pass through a lot of different method that already have
their own return signature and a simple exception is easier to manage.
Task: 1849912
When a manufacturing order was created through a stock rule, the `delay_alert`
feature was broken. Indeed, we should store on the order the `delay_alert` value
similar to what we do with the `propagate_date`, `propagate_date_minimum_delta`
and `propagate_cancel` fields.
We thus add the missing field and add the values in the multiple prepare methods.
We also the missing values for `propagate_date_minimum_delta` and `propagate_date`
in `_get_move_raw_values`.
task-2154781
closesodoo/odoo#42032
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Create Product A:
Routes: MTO and Manufacture
Manufacturing Lead Time: 20 days
- Create Product B:
Routes: MTO and Buy
Add a supplier with Delivery Lead Time: 10 days
- Create a BOM: 1 unit of B to produce 1 unit of A
- Create a SO for A, validate
A MO is created with a Deadline set at SO order date - 20 days => OK
A PO is created with order date set at SO order date - 10 days => Not
OK, it should be - 30 days.
In v13, the raw materials expected date is the order date.
In v12, this date is computed as: order date minus Manufacturing Lead
Time
However, in both versions the PO order date is computed as the raw
materials expected date minus Delivery Lead Time of the supplier.
This comes from a change in the semantic of 'Planned Date' and 'Planned
End Date'. In v13, the Manufacturing Lead Time is only taken into
account in the Deadline, while in v12 it was taken into account in the
Planned Date. However, the expected date of the raw materials still
relies on the latter, not on the Deadline.
In order to solve this, we apply the 'Manufacturing Lead Time' of the
product and the company to 'Planned Date', 'Planned End Date' and
'Deadline' when the MO is created. Note that the solution is still not
ideal in case no routing is set on the BOM since 'Planned Date' and
'Planned End Date' won't be updated later in the process.
opw-2118951
closesodoo/odoo#40360
X-original-commit: b523f991572e32e69c5f8000a21553191ca54773
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Usecase to repdroduce:
- Create a manufactured product with route manufacture and a RR
- Run the scheduler.
Orderpoint will prepare procurement values's date as string. Other
module could possibly also use string as date and a call to from_string
will not break anything if the value is already a date or a datetime.
closesodoo/odoo#38900
X-original-commit: e4c654f8e5e768288226c725a1018ae31e8f5606
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
If it isn't set manually, it defaults to now and the result is not
consistent with planned date end. We make it an hour before totally
subjectively.
closesodoo/odoo#37173
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The purpose of this commit is to simplify the `mrp.production` model in
reducing the number of date field.
The following fields was kept:
- `date_planned_start`: the planned date for the beginning of the MO
- `date_planned_finished`: the planned date for the ending of the MO
- `date_start_wo`: the preferred date to start a Work Order in case
the MO will plan one.
- `date_deadline`: is only indicative and is automatically set when
the manufacturing order is needed for a sale order.
- `date_start` and `date_finished`: no changes.
Task #1935229
Co-authored-by: Whenrow <whe@odoo.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Usecase to reproduce
- Create a BoM with finished product A and Comp C
- Create a RR on product A with min qty 10
- Product A is tracked by serial number and have route manufacture
- Run the scheduler twice.
The finished tabs in the manufacturing order created from the order
point contains 10 move lines with 1 qty reserved and 0 quantity done.
The first run created the MO. The second run, assign the finished moves
and thus created the move lines for finished product A.
However those move line are not used by mrp because the workorder and
the produce wizard will only create new lines instead of using existing
lines with reservation. Also action_assign on MO only trigger
_action_assign on raw moves.
This commit add a hook on scheduler in order to modify the domain that
will be used in order to search moves to assign. Use the hook in order
to avoid move with the production_id many2one set.
closesodoo/odoo#32597
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Default the responsible to the current user if the mo is created
manually.
Default the responsible to empty if the mo is created by a procurement
rule.
task 1938495
closesodoo/odoo#31395
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Production order are created in batch. Confirm them and
create their componenets moves in batch also. Adapt _get_moves_raw_values
method in order to be multi. action_confirm was already multi.
Improve the procurement requests performance. Instead of processing
procurement request one by one, search rules that apply for each of
them and group them by rule's actions.
The main technical change is the record creation order.
E.g. 2 SO lines with pick ship delivery.
-Before this commit:
line1 -> LAUNCH_RULE -> PICK MOVE1 -> MOVE1 CONFIRM -> OUT MOVE1
line2 -> LAUNCH RULE -> PICK MOVE2 -> MOVE2 CONFIRM -> OUT MOVE2
-After this commit:
line1/2 -> LAUNCH RULE -> PICK MOVE1/2 -> MOVE1/2 CONFIRM -> OUT MOVE1/2
Also there is one batch creation by company_id. It implies that values
are group by company_id. Since company_id are passed by previous
procurement or by the rule, it become a required value and it's added to
the procurement arguments (it was already always passed in the values,
no functional modification).
_run_buy is reworked. It receives a bathc of procurements, those
procurements could be merged in the same PO or the same PO lines.
However the PO/PO lines are created (if procurement couldn't be
merged in an existing one) at the end of the method. It implies
that 2 procurements creating a PO and merged inside, would now create
2 distinct PO (same for po lines). _run_buy in order to fix this issue:
- group procurements by PO search domain. If the PO doesn't exist,
create only one.
- Inside the same PO: merge quantities, move_dest_ids for procurements
with the same product and UoM.
Other _run_ methods are just adjusted in order to process batch.
For a pick pack ship scenario, without procurment_jit confirm a SO
containing 500 lines will take 40s instead of 15 minutes.
The purpose to set orderpoint_id on MO is to keep the behavior than
purchase_order. It's also a future work for procurement in batch because
after creating a production order, a note is posted with its origin.
Since orderpoint_id was not set on the MO, we would have to keep all
procurements values dict after MO creation and rematch them in order to
log the note with the origin.
The purpose is to be able to plan manufacturing order
without propagate the components's documents directly.
Except when the manufacturing comes from a pull rule, it will
be confirmed directly.
In order to do it, it will just create the moves without confirm them.
They will be only confirmed after a 'Mark as Todo' click.
Before this commit, the quantity_delivered of a kit was set to 0 unless all its components were delivered.
With this commit, the quantity_delivered is the minimal quantity it's possible to make with the components currently delivered.
TaskID: 1863856
This commit refactors the method '_bom_find' in order to search bom based on their type.
This allows to handle the cases where a Kit has the route 'Manufacture' set.
TaskID: 1863856
With this commit, the routes of the components of a kit are applied instead of the routes on the kit itself.
To do this, a refactor of '_adjust_procure_method' was made in order to use it on stock.moves
The method '_adjust_procure_method' was moved to the stock module in order to be used in a future task concerning repair orders ( TaskID: 1887961).
TaskID: 1863856
The purpose is to split up the supply chain in different group.
Currently if a user create a SO with a MTO manufacture product
that use MTO/buy components.
SO cancellation will:
- Cancel all the pickings including pickings between MO and suppliers.
- Log an activity on the MO but not cancel it.
We prefer cancel all transfers between SO and MO when the SO is cancel.
Cancel all the transfers between MO and suppliers when the MO is cancel.
Create a new procurement group when the _run_manufacture method is call
allows to achieve this behavior.
Currently MRP do not handle multi locations for components. In order to
be able to use both feature at the same time, we could:
- Improve mrp in order to handle multiple stock.move.line for a
componenet stock.move
- Add a rule that allow to bring all the good from multiple location to
a single location. (was already possible but it requires some
configuration)
This commit introduce a checkbox on the warehouse in order to
automatically configure all the routes/rules/locations/picking_types,...
necessary to bring all the components to a single location before
running the manufacturing order.
Technically it also refactor some stock_warehouse.py methods in order to
easily override the picking_type, rules and routes creation.
Thank to Hetashree Chauhan <hch@odoo.com> for his help.
task_id: 27785
Arnold Moyaux