This commit relax, by one second, two datetimes comparison regarding
workorder planning to avoid any false positives
closesodoo/odoo#33740
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
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.
Purpose
=======
In Belgium, we need to support some partial time on 2 weeks.
For instance, a mid time, means you could work on monday, tuesday
and wednesday on week1 and monday and tuesday on week 2. Others payroll
softwares manage this.
Specification
=============
Add a checkbox on resource calendar to manage 2 weeks. --> Consider even/odd weeks.
Add sections on calendars (Like sales orders)
Modify methods in resources to apply this behavor generically.
Check that attendances aren't overlapped
Write an integration test for holidays - benefits - payslip
to check all this, + "credit temps" and wage modification.
Note
====
For the sake of simplicity, we only manage calendars over 2 weeks
to consider the odd/even weeks and keep an easy implementation.
For more complicated calendars (eg: over a months with specific targetted days),
it's better to create specific allocation requests and apply specific leaves
for those days, as it would be the case for parental leaves.
closesodoo/odoo#31674
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* = account, mrp, purchase_stock, sale, sale_product_configurator,
stock_account, website_sale
It is always better to create the product template attribute lines before
creating the variants. In a following commit, this will become mandatory.
The variants that are created should always match the combination of attributes
set on the template.
Finally explicitly call `create_variant_ids` when possible instead of reassigning
the attribute lines to implicitly call `create_variant_ids`.
closesodoo/odoo#34122
Signed-off-by: Jérémy Kersten (jke) <jke@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>
Having 4 products and 3 BoMs:
BoM 1:
product = Finished
quantity = 100 units
- Semi-Finished 10 units
BoM 2:
product = Semi-Finished
quantity = 10 units
- Assembly 10 units
BoM 3:
product = Assembly
quantity = 10 units
- Raw Material 10 units (product.product 5$/unit)
Before this commit, the price for 100 units of Finished product was
500$, which is wrong. The price was calculated using 100 units of
Semi-Finished product and not 10 units as it should be.
Now, the price is 50$
opw-1973347
closesodoo/odoo#33115
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
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>
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.
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>
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
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>
Test was relying on qty_to_consume getting saved when the produce form
is saved, a behaviour of the SSF which diverged from the actual
client.
After fixing the SSF to behave more in-line with the actual
client (don't save o2m sub-fields unless they're flagged as
force_save) the test is now visibly broken.
Fix it so qty_done is properly updated during wizard configuration /
edition instead of updating the in-database object directly.
closesodoo/odoo#32047
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This commit ensures the qty_to_consume is always adapted to be the same
as qty_done in the onchange on qty_processing. This patch is needed to
keep the same behaviour before and after the workorder line refactoring
5ef46664a2
purpose: on a MO, producing via the 'Produce' wizard give the ability to add any additionnal product into the production.
The issue is that the UoM of the new line is empty and so will trigger an error later in the flow.
This commit add a new onchange on product_id to ensure the field product_uom_id will be set accordingly
closesodoo/odoo#31950
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Usecase:
- Produce 1 product not tracked
- Produce 1 product not tracked
The total number of finished product is 3
It happens because _set_quantity_done will
add the quantity and not set it to the quantity
passed as argument. In produce wizard it pass
as argument the quantity of move line + the produced
quantity. It will result as twice the quantity of the
move line + the quantity producing
Issue 1:
Usecase to reproduce:
BOM: 1 prod final F -> 2 unit of components C
- Create a MO of 2 units
- Reserve 4 units of C
- Produce 1 unit of F (produce wizard)
- Save
- Produce 1 unit of F
- Update quantity to 2
The reserved quantity in the wizard is 4 although there is 2 units
already done on the first operation. So it should remain 2.
It happens because the produce wizard did not take into account the
2 units already done on the first stock move line.
This commit fix by using ml.product_qty - ml.qty_done each time it's
needed.
Issue 2:
Usecase to reproduce:
SAME BOM
- Create a MO of 2 units
- Reserve
- update quantity to 3
- It creates a new line with to consume 2, reserved 0
- update quantity to 4
- It update the line 2 0 to 4 to consume 4 reserved
So we ended with 8 units of C reserved.
It happens because the system match the workorder line with the stock
move line one by one without a global view on what is reserved or not.
So the second workorder line found a move line with 4 reserved but 0
done and did not check the first workorder line that already use the
4 pieces reserved. So it considers it as available and take the
reservation a second time.
It's fixed by an iteration over workorder line instead of move line
and keep the used reserved quantity in a dict by lot.
Issue 3:
Usecase to reproduce:
SAME BOM
- Create a MO of 2
- Produce 2
- Update quantity to 3
New line with to consume 2 reserved 0
- Update quantity to 4
New line with to consume 2 reserved 0
It's bad since we would like a line 4 0 as in saas-12.1
It happens because _update_workorder_lines will always create a new
line with remaining quantity if it could'nt find one with reservation
to update. However the line could exist without reservation so it
should update it instead of creating a new one.
It's fixed by adding the remaining quantity in the first workorder line
without lot (if the tracking is serial it should continue to create a
new line).
When the user consumed more raw materials than reserved. The system
was supposed to take the extra quantities from existing stock and so
their location. However the reserved quantity is always lower or equals
than the quant quantity. reserved - quantity is always negative or equal
0 and the float compare after will always return true and the code will
never be executed and will return the move location.
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>
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
When retrieving the BOM lines in `_get_bom_lines`, we check the product
attribute values to know if the BOM line should be taken into account or
not. However, we do not do such a check when we retrieve the price in
`_get_price`.
It can lead to an inconsistency between the sub-lines displayed and the
total price.
We need to apply the same filtering logic when getting the price.
opw-1932437
closesodoo/odoo#30917
Usecase : create a bom in unit with a component tracked by serial and
quantity to produce = 1 unit
Create a manufacturing order with a UoM different that the bom one
(e.g. Production request = 1 dozen)
Launching the produce wizard or a workorder will show to the user
a workorder line with 12 component units to consume. But as the
component is tracked by serial. We would like to get 12 differents
lines of 1 unit. This commit take care of this specific case.
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
Haresh Shyara