rev [0] was incomplete, the
possible_bom_product_template_attribute_value_ids field was not computed
in mobile because parent_product_tmpl_id was not sent to the server.
rev[1] broke the normal produce wizard
[0] 5d5644c721
[1] 916b49381bclosesodoo/odoo#36595
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
This is a performance optimization: modifying a regular record will not
trigger some recomputation on a transient record. Most transient
records are simply waiting to be garbage-collected, so there is no need
to keep their fields up-to-date.
closesodoo/odoo#35909
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Usecase to reproduce:
- BoM -> 1 component for 1 final product
- Create a MO with a quanity of 5
- Update the quantity to 6
-> The move finished has an initial demand of 4
Modify tree view for MRP Production
Modify form view and tree view for Unbuild orders
Add group by for Bill of Materials
By default show line shart when opening MRP Production report
Modify view for Work Orders
Modify view for Work Centers
Modify view for Routings
Modify view for Maintenance Request
Modify view for Bill of Materials
task-2042304
closes - https://github.com/odoo/odoo/pull/35482
Usecase to reproduce:
- Create a MO for 5 final units
- Reserve all the components
- Produce 3 units
- Post Inventory (debug mode)
- Edit/Unlock
- Edit a line to consume to an arbitrary amount of quantity
- Change the product qty and set it to 3.
At this point, the reserved quantity and the quantity to consume
still the same than intialy even if the final quantity was updated.
- Mark as done
Then a move is marked as done withtout quantity done and still have
reserved quantity.
It happens because the _update_raw_move function do nothing if the
new quantity to consume is equals to 0.
The arguments returns in _update_raw_move still exists for override
but are not used by the chang_prod_qty method. It's not possible to
cancel the move and then find its parents in order to log the activity.
opw-2023653
closesodoo/odoo#34471
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
The production.move_raw_ids usually contains only one move per bom_line_id;
it might not always be the case, as ccbd6712f6 used move[0] to get a singleton.
The following calls to _get_document_iterate_key, _log_activity_get_documents,
also require move to be a singleton, so we use replace move by move[0].
opw 2042099
closesodoo/odoo#35206
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before Commit:
If a product type service in a bom, create a manufacturing order
of product's bom they returns empty recordset because if product
type is not storable and consumable is returns empty object of
stock move else they returns the data dictionary.
After Commit:
If product type service in a bom, create a manufacturing order
we returns the empty dictionary rather than empty object of stock move
Add a testcases
1) to check manufacturing order is generated of product
type of service in bom or not.
2) to check manufacturing order is generate from sale
order of product type sevice in bom or not.
Task ID - 1981790
closesodoo/odoo#33337
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this commit, you can delete only canceled MO.
Now, if you want to delete a non-canceled MO, it will try to cancel it
then to unlink it.
Task #1969034closesodoo/odoo#34026
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.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'`
Since previous commit moved decimal_precision module's feature into base,
use the new syntax for fields declaration
Remove the imports to the removed module
Remove the module from dependency in manifest
sed -i "s|digits=dp.get_precision('\([A-Z a-z]*\)')|digits='\1'|" **.py
sed -i "/from odoo.tools import decimal_precision as dp/d" **py
The method _workorder_line_ids() is defined on mrp.workorder while `self`
is an instance of change_production_qty wizard in this case. Without this
commit, changing the quantity to produce of a manufactoring order with workorders
already planned raised a traceback.
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.
Task 1937686
closesodoo/odoo#31243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
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.
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>
When registering lot or serial number for a component in a workorder,
the manufacturer can create it on on the fly. We would like to give this
ability a restriction depending on the picking type.
This commit blocks the creating by default but leave the possibility to
tick a new checkbox on the manufacturing picking type to allow the
creation of lot and serial number for components inside the production process.
Task : 1891864
Purpose: The quantities to consume on Bill of Material lines should be
either strictly used or be taken as a reference more or less adjustable.
This commit adds a setting on BoM to specify if the consumption is 'strict'
or 'flexible'. This new option has the following impacts:
On produce wizard: if consumption is set to 'strict', the done quantities
are prefilled and checked when saving the wizard. If set to 'flexible',
the production flow remains the same as present one.
On workorders: if consumption is set to 'strict', the Validate button
will save the consumed data, and propose to fill the remaining ones until
the total is registered. If set to 'flexible', two button are displayed.
'Validate' to register the current component and pass to next step either
the quantity to consume is complete or not, and 'Continue Consumption'
to registered the current component quantity but leaving the user the
possibility to add more quantity (and possibly another lot number) for
the current component
This commit also revert partially d3617fd852
as the warning become some sort of an error
Task: 1889393
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
Before this commit, when a product goes from manufacturing order to
location having putaway strategy, if this product is tracked, the
putaway strategy don't apply.
opw-1948514
closesodoo/odoo#31808
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit, the fields qty_reserved and
qty_done were displayed in the wizard with a
precision of two digits (for each case).
The problem is that the qty_to consume uses the
precision accuracy defined in 'Product Unit of Measure'.
It resulted that a quantity of 0.002 to consume
was translated to a qty_done of 0.0.
See opw-1949198
closesodoo/odoo#31822
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Usecase to reproduce:
- Connect with demo user
- Create a MO w/h routing
- Confirm and produce it
- Record the production wizard
Access right error on product.product for field tracking
It happens because the wizard use a related to product.tracking howerver
it is not set as readonly on the view and send to the server as a value
on save. Since it write on a related field it will try to write on the
linked model(product.product).
This commit set the field as readonly so it is not set to the server.
The field is just used inside domain and it is invisible to the user
so it do not modify any behavior.
opw-1918684
closesodoo/odoo#29942
Suppose you have a workorder to create n units of product P,
using raw material R (suppose we use one for one, the following can be extended
to any number of raw materials and factors in a straightforward manner).
Produce j < n units of P. Next, update the quantity to produce to j < k < n.
Since any number m of units between j and n may already have been reserved,
in particular values such that m > k, the move will unreserve the material R.
However, while doing so it will unlink the move_lines, and lose the
quantity_done (j).
The newly created move lines have a quantity_done of zero by default.
Therefore, we store in a dictionary the quantities done for each move line,
and reset these values once the unreservation/reservation of k units is done.
opw 1911969
closesodoo/odoo#28990
commit e1e0826eee introduced a button in
order to quickly add a lot number on the current production. However on
the produce wizard it will create the lot, save the wizard with the new
lot and reopen its view in edit mode. However the qty to consume and
reserved on the produce lines are readonly thus not saved and lost
during the process.
This commit add force-save on the qty to consume and reserved
closesodoo/odoo#29925
Simon Lejeune