This commit rename product_uom_qty into reserved_uom_qty and product_qty
into reserved_qty on stock move line to stop mistake them with the stock
move quantities fields.
Task: 2648449
Part-of: odoo/odoo#80434
The stock convention on location name is always to name the destination
`location_dest_id`. It was not the
case on the stock rule model
Task: 2648449
Part-of: odoo/odoo#80434
In a lot of test class, we use `setUp` instead of
`setUpClass`. `setUp` is execute for each test method and `setUpClass`
will be execute only once by Class (and use savepoint + rollback).
Then change setUp into setUpClass reduce the time to make all tests
and avoid to repeat this error for the future.
closesodoo/odoo#78082
Related: odoo/enterprise#21563
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
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
In this commit:
- On done MO's form, add an Unbuild button, it would open a
wizard with the form view of an unbuild, and some pre-filled fields
such as MO, product, BOM, quantity and total quantity finished which
can be edited.
- In the unbuild order, improve the on_change of mo_id:
if the selected product is tracked by serial number,
set quantity to 1 by default and readonly
- Also clean the testcase of unbuild order.
task-2144636
closesodoo/odoo#43719
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Co-authored-by: Ankita Raval <anr@odoo.com>
`action_done`on pickings should be a private method,
and called only trough the picking validation process.
task-1938108
closesodoo/odoo#39174
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Ensure proper domains are applied and enforced on relation fields thanks
to the `check_company` attributes.
Make sure unbuild have proper sequence for each companies.
The produce wizard and workorders company is the one of the production.
The BoM line company_id is the one of its bom_id.
Added some tests.
task-1985992
Commit 5ef46664a2 share code between produce
wizard and workorder. Field final_lot_id is now commonly used but not very
well named. This commit rename it into finished_lot_id as it represent the
lot number of the finished product.
Task : 1998064
closesodoo/odoo#32761
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
In MRP the tracability is only set between the finished
products and the components. However when the by-products is
tracked by serial number, it could be usefull to know from which
components it was created. This commit add the link between by-products
and raw materials (only in produce wizard at the moment).
Technically we replaced the one2many field by a many2many.
Technical refactoring in order to set by-products the same way
than raw materials. Before this commit byproduct were always set
at the last workorder or automaticaly set at the end of produce
wizard with the same quantity than in the BoM. In order to modify
it, the user has to produce the finished product then unlock and edit
the finished move line linked to the byproduct. In this commit, the
user could specify at which workorder the byproduct is created and
he could directly specify another quantity done in the produce wizard
inside a specific tab for by-products.
Technicaly, abstract workorder will add a new many2one key on workorder
line in order to set 2 different one2many (one for finished goods and
the other for raw materials). The key is set depending the many2one
key for production on the linked stock move. On the by-products itself,
it is now managed as a workorder line, thus the code to generate them
and transform them in a finished stock move line is the same than for
the raw components.
To record a production via a manufacturing order, the user can either
use the produce wizard or the workorders views. Those two objects was
technically different but act more or less the same. This commit aims to
merge the similar behaviors in common code
We introduce two new abstract models :
1. Abstract workorder to share workorders and the produce wizard
2. Abstract workorder lines to share active_move_line on workorder and
product_produce_line on the wizard. Those abstract line keep the information
about the quantities and lot number to put on component move lines and
finished product move lines
Task : 1891864
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.
Finished product moves from a MO where created without warehouse_id.
It implies that push rule based on warehouse where not trigger on those
moves confirmation.
This commit adds warehouse_id on unbuild/production's finished/raw
moves. It also add a test for this behavior.
Task ID - 1865574
New test :
- Create a MO with a finish product tracked by SN with a dozen as
quantity
- Click on produce button in order to open the produce produce wizard
The quantity to do is 1 dozen although the tracking is by serial number
Task #55494.
When producing a finished product with a lot, also the raw materials
without lot tracking should split the move lines to at least know the
quantities consumed for every lot produced. This way, the traceability
report will not confuse the user.
Since the function in order to generate a MO is usefull
for mrp test. It could be great if we could use it in
every test.
This commit also add 3 arguments in order to modify the
quantity needed for each product.
Before, in case of non-tracked components, when everything foreseen had
already been consumed, it would not add the theoretical quantity on
producing through the produce wizard. This makes little sense as the
behaviour of the wizard is not the same anymore for all cases and this
can only confuse the user.
Suppose you have a product tracked by serial number. In your inventory,
you have two quants: -1 for serial1, +1 for serial2.
If you create a move for 1 product and try to run `action_assign`, it
didn't work before this patch because stock.move's
`_update_reserved_quantity` is guarded by a call to
an unstricted `_get_available_quantity` (unstricted meaning considering
all quants regardless of their lot_id/package_id/owner_id). This call
resulted in an available quantity of 0, thus the stock move could not be
reserved
To fix this issue, we patched `_get_available_quantity` so that it
rightly considers products of different lot_id as different products,
i.e. it returns an available quantity of +1 in the initial scenario. Of
course, we consider all quants of the same lot_id, i.e. if you have -1
for serial1 and +1 for serial2, the available quantity amounts to 0.
In another scenario, let's say we have only -1 serial1 in stock, if we
run `_get_available_quantity`, the method should return 0: nothing is
reservable. We continue this reasonment by returning 0 everytime the
available quantity is negative, tracked or not. This is probably what a
method named `_get_available_quantity` should have done since the
beginning.
There's only a single case where we need to know the quantity even if
it's negative: it's just after we move a quant to its destination
location. If this quant was tracked and resulted in a negative quant
(i.e. we moved something we didn't have), we try to compensate with an
untracked quant. In this special case, we do not want to ignore the
negative quants when calling `_get_available_quantity`. That's why we
introduce a new argument to this method. We could have added a new method
`_get_quantity` for clarity sake.
Since refactoring in saas-17 quant_ids are removed and
the logic is instead locate on stock_move_line. This commit
adapt the method by trying to undo the created move_line
during the MO.
This commit also add a default_uom_id in the view's context in order
to remove a traceback. Since 0469d2e
uom is mandatory on stock_move_line.
It also add a bunch of tests in order to check the behavior of unbuild
with 4 test: without tracking, consumed product tracking, produced product
tracking and everything tracking.
Know limitation of this commit:
-> No warning message when unbuild more than in stock.
-> Wrong result if trying to unbuild twice the same MO
with consumed product tracked with different lot/SN
William Henrotin