cancelling propagation in a move chain was True be default. That means,
without any configuration, a cancel move will always cancel its next ones
This commit change the default to allow only cancelation of move chain
until the stock location. Here are 2 examples :
1. Reception and delivery in 3 steps. The moves chain is the following:
Vendor -> Input -> Quality -> Stock -> Pack -> Output -> Customer
In case the Purchase order is cancelled, we want to move from Vendor to
Stock are cancelled but not the ones from Stock.
2. pbm + sam. The manufacturing process is the following;
Stock -> Pre-prod -> Production -> Post-prod -> Stock
cancelling the first move should cancelled until Production and not after
Task : 1913297
Steps to reproduce the bug:
- Create a product template A with variant color: black and white.
- Create attribute : size : 16gb and 32 gb
- Create a bom with template A.
- Add a bom line L with product B
- Save the bom ,edit it and select an attribute value for L
Bug:
All attribute values of the database (color: white, color: black, size: 16 gb, size 32 gb)
were displayed.
opw:2006988
closesodoo/odoo#33949
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- Set the products tracked by lot
- Set 1 route with steps that allow to begin next one after a minimum
amount processed.
- Plan and begin the manufacturing process.
- Process partially step 1, but fully step 2
- Finish step 1
The error 'You can not change the finished work order.' is raised.
This is because we try to set the default final lot on a WO which is
done.
This is only used to suggest the right lot number, so we can safely skip
the step if the WO is done or canceled.
opw-2002044
closesodoo/odoo#34072
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a MO for '[FURN_8855] Drawer'
- Consume 1 unit of '[FURN_2100] Drawer Black', but DO NOT consume
anything for '[FURN_5623] Drawer Case Black'.
- Complete the MO, then Unlock it
- Edit the '[FURN_5623] Drawer Case Black' line
It is not possible to add a line.
This is expected from 9e77ce2edc, but we still want to be able
to consume some quantity.
Instead of canceling the move lines without any quantity consumed, we
set it to done.
opw-1986919
closesodoo/odoo#33820
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
Usecase to reproduce:
- Install stock, mrp, purchase
- Go on warehouse form view
- Click on Routes button
Either one of the route manufacture or buy is missing.
All implementations/overrides of stock.warehouse._get_all_routes()
call their parent's implementation of get_all_routes_for_wh().
which is a reference to stock.warehouse._get_all_routes() but that means
that the route 'mixin' behavior can be skipped.
(the reference is to the base implementation of _get_all_routes())
Fixes#33286Fixes#33288
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Posting intermediate inventory in a manufacturing order using workorder
need to delete all the remaining workorder lines.
The post_inventory method create new raw moves for the remaining quantities
then reserve those quantities. The reservation will create new workorder lines
If the old workorder lines are not purged, the workorder will be asked to produced
too much.
closesodoo/odoo#32948
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The quantity to consume for a component is computed in different places
(community and enterprise modules, workorder and produce wizard) during
a production. This commit share those computations into a static function.
closesodoo/odoo#32864
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Usecase to reproduce:
- Create a MO for drawer with SEC assemble BoM
- Plan the workorders
- In the first workorder record the production without specify a lot or
serial number.
- Second workorder, register a new serial for finished product and
record production.
A UserError that prevent to use a new serial number is raised. It
happens because the system check the remaing quantity on other
workorders + the quantity already produced for the current lot. In this
case the remaining quantity for the first workorder is 0 and the current
lot was not produced. However it should count the lines without lot as
a 'remaining quantity' since they could be used later to create a new
serial or lot number.
This commit register the lines without lot and use them to raise the
UserError and compute the allowed lot domain for finished lots.
closesodoo/odoo#32632
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Commit 84ae731d5d used 'self.code' in a method
called by a multi one. As 'self.code' expect a singleton, the transaction
raise an error in case of multiple records into the recordset
This commit calls the method into a loop on 'self and change its signature
to pass 'code' and be sure its a non multi one
subproduct and byproduct are both used in code.
However the UI always shows by-product only.
Rename sub.product, sub_product,... in byproduct
in order to use the same term everywhere.
closesodoo/odoo#32540
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Be consistent with by-products and byproducts. Only use by-products.
When a product is created from the BoM view, it has a default type
as storable product, set the same type when the product is created
from by-products tab.
Usecase to reproduce:
- BoM with final product tracked by SN
- Produce wizard add a component tracked by SN (not from BoM)
- Produce and mark the MO as done
The tracability report do not show the extra component used.
It happens because _record_production call _action_done on moves raw
and finished. _action_done create extra move with moves that created
more than expected (the purpose is to trigger rules). However in stock
the new move is created then merged in its parent but in mrp moves are
not merge. _record production set the tracability for initial moves but
ignore the extra moves created. So the tracability report is not
complete.
Fix it by catching the new moves created after _action_done and set
the consume_line_ids for the extra moves also.
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.
Unbuild a manufacturing order only undo the final product and its
components. The byproduct created will not be undo with the correct
ratio. This commit will allow to undo a ratio of byproducts for a
specific MO or base on the BoM if the byproducts are not tracked.
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.
Enforce the domain of the UOM not by an onchange but by a domain.
Exemple of issue if the domain is enforce by an onchange:
- create a picking
- add a move
- select the product
- select an uom
> the uom presented are the one from the product category.
-Save
- edit
- select an uom
> all UOM are presented even the ones of other categories
This commit enforce this new logic at most places.
task: 1886272
closesodoo/odoo#33083
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose: link workcenters that can do the same job together.
Planning a workorder will be done by choosing, among the similar
workcenters, the one that will finish the production the soonest.
This commit adds a new many2many field on the mrp.workcenter
model. Planning the workorders will:
1. Loop on the operation's workcenter and all the alternative ones.
2. Compute the first available work slot for each of those workcenters.
3. Choose the soonest finished slot
Furthermore, planning workorder is done thanks to the resource module.
Each workorder is saved on its own workcenter calendar by a resource.calendar.leaves
The two date fields are thus computed from the leave date.
Task : 1892819
closesodoo/odoo#33018
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
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 clicking on 'In Progress', 'To Launch' will open a list view instead it
is needed that, clicking on those links will open tablet view in enterprise and
list view in community.
And also, to remove xpath (from enterprise) because they are not generic
and can only be applied at one element at a time. Instead, a method is defined
by this commit which is overridden in enterprise to open kanban view.
task - 1967745
closesodoo/odoo#32815
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Purpose
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closesodoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Usecase:
- Go on a BoM with a routing. Go on the first operation and set
the next operation(batch field) as 'Once a minimum number of products is
processed'.
- Set the batch size (minimum operation) to 0.
- Create a MO and plan it.
- The second work order has state 'pending' instead of 'ready'
It happens because the system automatically set the first wo as
'ready' and the following as 'pending' and don't check the batch
and batch_size.
closesodoo/odoo#32628
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
On a manufactoring order, 'checking availability' will make the reservation of
the components to consume. If those components are tracked by lot or serial numbers, the
reservation will also set a available lot/sn on the move lines and workorder lines.
The reservation already works on product produce wizard lines and workorder line
(form view). We need this commit as preliminary work to being able to suggest them
on the workorders tablet view too.
In case of requesting the reservation after planning the production (applying
reservation on already created workorder lines and checks), we deleted all lines
not yet consumed. They are then recreated with the reservation.
The user can obiously still use the lot/sn he wants by changing it onto the
workorder.
Task : 1891864
closesodoo/odoo#28020
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This commit allows the user in charge of manufacturing products to
split his production into different lots if this production is done via
workorders. Using a lot in a workorder will adds constraint to all the
other ones. It will also prefil the final lot field and matching quantity
to produce for futur workorders.
This commit uses workorder lines (in another one2many as standard workorder_line_ids)
to register lot/serial number and produced quantity. Prefill lots and
quantities are all read from those lines
Task : 1891864
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
product_location was confusing, not correctly working and is now
replaced by a new feature to manage subcontracting correctly.
TaskID: 1915022
closesodoo/odoo#32390
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
In a few words, it allows to send components to a subcontractor partner
and receive a finished product. The production is managed through classical
manufacturing orders where the raw and finished location is the
subcontracting location. When creating a receipt picking for a
subcontractor partner, the location_id of the moves will be set to the
subcontracting locations by using the property_stock_customer and
property_stock_supplier of the partner. An override of _action_confirm
will create the manufacturing order.
When a subcontracted bom contains tracking, the produce wizard is
available from the picking to record which lots were produced/consumed.
New type on the BoM: subcontract
New type on res.partner: subcontactor
New location per company (we still own the components stored at the
subcontractor so they're still valued)
New routes created to resupply the subcontracting location on order or
not (through a reordering rule).
Override of res.partner to set the property_stock_customer/supplier on
subcontactor partners.
Proper tests were added too.
Joint work with: Arnaud Baes <arb@odoo.com>
task 1831382
Christophe Simonis