Previous commit 1b840d066999bde1f05563567f439967770701ca tried to fix
the issue action_generate_serial may try to generate a existing lot.
But it made the lot number completely product specific. This change is
too big for stable, we revert the change in this commit.
Also to fix the issue, when action_generate_serial tries to generate a
lot, we always try the result from ir.sequence frist, only when the lot
already exists, we then try create one based on the product's lastest
lot number.
Task-3187003
closesodoo/odoo#121214
X-original-commit: 95214ab6c133553371926804e788766edab2b8ca
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
Steps to reproduce:
Step 1: Create new MO
Step 2: In page by-products click three dots to show column cost_share
in tree by-products
Step 3: Create new Byproduct and input cost share >100% or <0% or input
two byproducts
where their cost share adds up to more than 100%
Expected result:
Validation error: total byproduct cost_share cannot exceed 100
or Validation error: cost_share values must be positive
Actual result:
Values saves without issue
Issue is due to `move_byproduct_ids` being removed in the mrp_production
overrides of
`write()` or `create()` and having the `_compute_move_byproduct_ids`
populate its values.
This removal is causing the constrains to not be enforced, therefore we
set the constrains
field to `move_finished_ids` since changing of this value will ensure
that the values are
correctly checked.
Note: There will be a decrease in performance since this means the
constrains will be
called whenever the MO's product to produce is changed, but hopefully it
will be
minimal since there is no simple fix for this issue.
closesodoo/odoo#120797
X-original-commit: 9d6ff93d0f5b39e939f632486a97093b59d335ef
Signed-off-by: Tiffany Chang <tic@odoo.com>
Previously WO duration per unit was not getting updated in WO report, since
there was no code for updating WO duration per unit while triggering immediate
production.
With this commit, WO duration per unit is updated in WO report when immediate
production is triggered.
TaskID - 3251232
closesodoo/odoo#120782
X-original-commit: 1c34d2875741da820212d5d781603fc9b270464a
Signed-off-by: Tiffany Chang <tic@odoo.com>
The finished move of a production order should be deleted if we change
the product to avoid having draft stock move detached from any business
documents
closesodoo/odoo#118957
Task: 3172098
X-original-commit: 4478560d7769a8a795a94aead875e02d1394dd71
Signed-off-by: Adrien Widart <awt@odoo.com>
Some demo data bill of material have workorder operation. Trying to use
them without the workorder setting activated will give an error on some
fields not instantiated.
This commit activate/deactivate the operations depending on the
workorder setting.
opw - 3229621
closesodoo/odoo#119254
X-original-commit: aaba4eb4deb3f9e10fd611924c5a24680d633537
Related: odoo/enterprise#40092
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Issue :
- When mass producing a tracked product, an User Error is raised on validation of splitted MO.
Reproduction :
- Create Serial storable product "Component A", Lot storable product "Component B", Serial Storable product "Finished Serial Product"
- Immediate Transfer 10 * "Component A" and 20 * "Component B"
- Create a BoM for "Finished Serial Product", consuming 1 * "Component A" and 2 * "Component B"
- Create a Manufacturing Order for 10 * "Finished Serial Product" and Confirm :
- Click on "Mass Produce", Set "First SN", Generate all the serials and Apply
- Click on "Produce All"
Task : 3274962
closesodoo/odoo#118592
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce the bug:
- Install purchase, then mrp (in this order)
- Create a storable product “P1”
- route: buy
- Add a supplier
- Add a BoM
- Create a delivery for the product “P1”
- A need is created
- Go to inventory > operation > replenishment
Problem:
An orderpoint is created with the preferred route: Manufacture instead
of buy
As the "Purchase" module was installed first, the override of
the `_set_default_route_id` function will be triggered first, the 'buy'
route will be set in the created order point because the product has a
supplier. Then, the function in the MRP module will be triggered and
since the product has a BoM, the 'buy' route will be replaced by
"Manufacture".
opw-3228971
closesodoo/odoo#119172
X-original-commit: 227d038efbadf25e3a7be7cceedd9159b71162a3
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When Operation is 'Archive' and it is still in use as 'Consumed in Operation' in
bom while creating Manufacturing Order and confirming it, KeyError will be
generated.
Steps to Produce:-
1) Create a new product, create bom for that product, add components, and
create or add at least 2 operations to the BoM.
2) In the components of 'Consumed in Operation' add the newly created operation.
3) Now, Archive one operation.
4) Create new Manufacturing Order with a newly created BOM
5) Try to confirm it.
KeyError will be generated.
By applying this commit, if there are no operations left after archiving
one linked to the component then the server error won't occur
sentry - 4042593205
closesodoo/odoo#119098
X-original-commit: ba2364f9188ff44c68a1b86d5029884815a33216
Signed-off-by: Tiffany Chang <tic@odoo.com>
When using message_post, the body format must be explicitly specified.
If html is expected, a Markup object should be used.
If text is given, the content will be escaped.
Before this PR:
message_post was unaware if the content of a message was HTML or
text. This lead to multiple situation where the content was
incorrectly considered as HTML and led to display errors.
In
self.message_post(body="Hello %s!" % self.name)
if the name contained HTML, it would be evaluated.
In
self.message_post(body="Contact Raoul <raoul@caramail.be>")
the email would not be displayed as considered as unknown HTML and
discarded by the sanitizer
Now each call must explict the type of content.
Use the escape() helper to properly combine Markup and translations.
It would also be acceptable to use Markup() to wrap a static
translation but escape is better as one can not guarantee the content
of a translation.
closesodoo/odoo#111850
Related: odoo/documentation#3612
Related: odoo/enterprise#36728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
duration_percent field is a stored integer.
In postgresql, integer are 4 Bytes long, which create a range of -2147483648 to +2147483647.
With a small duration_expected, and a big duration, we can easily break these limits.
OPW-3253333
closesodoo/odoo#117744
X-original-commit: 97892d04341a2cbbe07e4db6442a451b0cf0b164
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David <dafr@odoo.com>
Steps to reproduce the bug:
- Go to the warehouse settings:
- enable “3 steps for manufacturing”
- Create a storable product “P1” with 2 BoM
- Create an orderpoint:
- Preferred route: Manufacturing
- Product: “P1”
- BoM: select the second BoM
- To order: 1
- Click on the “Order once” button
Problem:
The manufacturing order is created with the first BoM instead of the
second.
As we are in 3 steps, the “run_pull” function is triggered first, with
values prepared from the orderpoint so the bom is well set:
https://github.com/odoo/odoo/blob/16.0/addons/stock/models/stock_orderpoint.py#L515-L523
Then the “run_manufacture” function is triggered but with vals prepared
from the move, not from the orderpoint, so we lose the BoM information
that the user has selected:
https://github.com/odoo/odoo/blob/16.0/addons/stock/models/stock_move.py#L1334-L1340
opw-3217945
closesodoo/odoo#117732
X-original-commit: 2371cd29e1c0cfa54b682b2100b9db7f5633a7b4
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Create a second warehouse WH02
- Let WH01 be the existing one
3. Create two storable products P_compo, P_finished
4. Create a BoM:
- Product: P_finished
- Components: 1 x P_compo
- Operation Type: "WH02: Manufacturing"
5. Create a MO:
- Product: P_finished
Error: Once the product is set, nothing defines the BoM (and
therefore the components, picking type, and so on)
When opening the MO form, the picking type is directly defined with
"WH01: Manufacturing". Therefore, when looking for a BoM, we use
that picking type as criteria -> we will not find the BoM of step 4
Notes about the fix:
- Small behaviour change: once the picking type is set, it does not
change automaticaly (whatever the BoM is)
OPW-3122384
closesodoo/odoo#116515
X-original-commit: 93381af48e20a10c3fded88f010f89cd03cc5131
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Steps:
- Enable `Worder orders` in Manufacturing settings
- Create a manufacturing order with a bill of materials and workorder operation set and confirm
- Go to the workorder tab and start, then finish after few seconds
- Update the real duration
- Try to save
Issue:
User Error
Cause:
When writing on a `mrp.production` object we check if the production is still planned and if, it try
to plan all the workorders which are not done or cancelled. But in our case all the workorders are done
so it try to write to an empty object.
opw-3230310
closesodoo/odoo#116122
X-original-commit: 674f37fbbaa4a0d7f34f8d75d16dd11373815932
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djoumatchoua Eteil Junior (etdj) <etdj@odoo.com>
while we are creating a new record of the mrp.workorder from the editable list
view (mrp_production_workorder_tree_editable_view), we are getting the singleton
error, as it is not taking any production record.
by applying this commit, it will resolve that singleton error
sentry - 3982694755
closesodoo/odoo#115862
X-original-commit: 91e7d36a48d58aea1d63999dd150b543983aeba1
Signed-off-by: Tiffany Chang <tic@odoo.com>
Existing constrains method had a bug in it, so let's take this
opportunity to replace it with the more efficient _sql_constraints
check.
closesodoo/odoo#115613Fixes: odoo/odoo#92799
X-original-commit: 0751a0e27b653d5c471120ba7f5dea37a3f30a28
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
A lot of issue with "It is not possible to unreserve more products of ... than you have in stock".
It's the result of a desynchronisation between
`stock.move.line`.`reserved_qty` and `stock.quant`.`reserved_quantity` fields.
It should never happens in theory. However we already faced it a lot due
to bugs/custom code/server actions... It's not trivial to fix because
the issue come from data corruption. So it is hard to spot the different
main issues.
In order to avoid it, this commit try to modify the structure of stock
module. Before the operations was made in this order:
- The `stock.move` checks the quantity available on `stock.quant`
- The `stock.move` write the quantity reserved on the `stock.quant` and
save it in a variable
- The `stock.move` create a `stock.move.line` with the quanity reserved.
The main issue is that a `stock.move.line` could be easily created with
a reserved quantity while the `stock.quant` are not update nor checked.
After this commit the operations will be:
- The `stock.move` checks the quantity available
- The `stock.move` dispatch the available quantity among the `stock.move.line`
based on create or write calls.
- The `stock.move.line` reserve the quantity on `stock.quant`
- If the quantity is bigger than available, we write the max available on
`stock.move.line`
The idea is to respect the different layers
`stock.move` <-> `stock.move.line` <-> `stock.quant`.
Avoid the interactions bewteen `stock.move` and `stock.quant`
This behavior is already well managed in other use cases.
E.g. the real quantity itself, `_do_unreserve` of `stock.move`,...
opw - a lot
Part-of: odoo/odoo#115328
The value of the timer was wrong when timesheeting with multiple employees
at the same time.
The problem was that the compute duration already takes the current timesheets
into account. So the problem was that we added some time
that was already in the duration
task id : 3216277
closesodoo/odoo#114901
Related: odoo/enterprise#38007
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This commit add a mass start and stop buttons that allows to start
or stop multiple workorder at the same time.
Starting a workorder checks if the user needs to be logged and
if the workorder is not blocked.
This commit also change the appearance of the mark as done button
task id : 3216277
Part-of: odoo/odoo#114901
Fix the isuue that manual consumption is not correctly calculated when
backorder/split/merge.
closesodoo/odoo#115429
X-original-commit: d72ddd80d8a6aaa808c07db685972a1c05e8d6a4
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Since starting a workorder and marking it as done replaces the
planned dates with the actual ones,
there is no need to keep dates which will always end up being the same.
task: 3108291
see odoo/enterprise#36102
see odoo/upgrade#4247closesodoo/odoo#110550
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
when plan workorder, cancelled/done workorders are taken in to account
when they block current workorder. In this fix, we ignore then when plan
workorder.
Task-3126569
closesodoo/odoo#114940
X-original-commit: 1b629659cb651c62fdd2c880ae591f9a9bb2e1eb
Related: odoo/enterprise#38020
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit, updating a purchase quantity of subcontracting
product will try to not merge the new and old move to keep the two chain
separated as much is possible and avoid side effects (receipt move,
subcontracting moves, resupply moves). Some were merged, some cancelled,
...
This had two issues:
First, not merging the quantity was not guarantied
as you can specify you don't want to merge them with others but it's not
possible for a stock move to say to any other move do not merge with me.
Second, by not merging the receipt moves, we duplicate every other
object on the chain. This pollute the database uselessly.
opw-3147446
closesodoo/odoo#114739
X-original-commit: 0b1bcfacb13c7de480f30015b91db11ed03f2dfe
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Go to decimal accuracy > product unit of measure
- Change the Digits from 2 to 4
- Create a storable product “P1”:
- Create a BoM:
- Add 1 unit of a component
- Create a MO:
- Product : P1
- Qty to produce: 41,0654
- Confirm the MO
- click on Action and try to split the MO in two:
- MO_1: qty 35,9757
- MO_2: qty 5,0897
- Validate the split
Problem:
A user error is triggered, “Unable to split with more than the quantity
to produce.”
While (35,9757 + 5,0897) = 41,0654
we have to use `float_compare` to avoid this kind of error
opw-3178441
closesodoo/odoo#114672
X-original-commit: dbaf8da533f4587f5ca9b0b82bea46488ba6e05a
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Apply propagation mechanism to Manufacture rules,
except the ones from the mto rule.
Also fix some _find_global_route having missed route's rename.
closesodoo/odoo#107952
Task: 2907698
Related: odoo/upgrade#4342
Related: odoo/enterprise#34963
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The parameter in search() is redundant with method search_count(), and
was making the calls less readable.
The method _search() is aimed at always returning a Query object. The
method can therefore never return an integer, hence the removal of the
parameter. This does not actually remove any functionality from the
method; counting result is simply given by using it differently.
Part-of: odoo/odoo#112126
The workorder wizard helping to track the time spend on the workorders has been automated.
The name of the employee will automatically be the name of the admin of the session.
The productivity will also be updated based on the duration
The duration, start date and end date will update based on the two other ones.
This changes will ease the addition of time trackings.
closesodoo/odoo#107473
Related: odoo/enterprise#34786
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This main feature of this commit is adding the possibility to login with multiple employees on the list view of workorders.
There is now a button in the header that will allow to log in as an employee in the list view.
The flow is the following :
- The employee logs in
- He becomes the "admin" of the session and his name appears next to the log out button.
- If another employee logs in, he will become admin and the first one will no longer be visible in the header.
- The employee will start timesheeting on the workorder if he press the start button. Notice that the employees working on the workorder will appear in the last column of every work_order record.
- If this second employee logs out, the first one will not become admin automatically. He will first need to click on his name/avatar in the popup and will be asked his pin code (if needed) to log in again.
There is also a way to assign employees to a workorder.
A filter will help retreive the workorder on wich the admin of the session has been assigned.
In addition, a new button in the header allows to mark as done multiple workorders at once.
The timer component has been updated to avoid wrong values if the computer goes to sleep mode.
The wizard of the workorders allowing to see the time traking has also be modified (switching tabs).
From a more technical point of vue, the employees and admin will be saved in the session.
The employees working on a workorder will be saved on the record.
related : https://github.com/odoo/enterprise/pull/34786
Part-of: odoo/odoo#107473
Currently, if the user change qty_done on any raw moves without
changing qty_producing on the MO, it's not possible to validate the
order. In this commit, we make it possible to validate the order as an
immediate production.
When qty_producing is 0 and validate the MO:
1. manual consumption moves: current consumed qty will be kept when
process the MO.
2. non-manual consumption moves: For tracked components, if
use_auto_consume_compoents_lots checked, and there is enough products
reserved, the qty_done will be filled, otherwise, an error will be
raise to ask user to fill in lot/sn. For non-tracked components,
qty_done will be filled.
Task-3116125
Part-of: odoo/odoo#113538
When use_auto_consume_components_lots is on, it's always no manual
consumption on a MO even when the product is no tracked. Fix it
Part-of: odoo/odoo#113538
On the BOM, we add "Consumed in Operation" to a line, manual consumption
will be ticked automatically. In this commit, we make it that when
remove "Consumed in Operation" on a line, manual consumption will be
automatically unticked.
Task-3116125
Part-of: odoo/odoo#113538
Previously we set a component on MO to be manual consumption by comparing
the To Consume and Consumed, if they are not the same, we consider it a
manual consumption. Now if any input activity in the Consumed cell, we
will consider it a manual consumption.
Note that in the code, we make the css class change happended in the
list renderer instead of the field widget. We do that because we want to
change the background color of the whole cell not just the text of the
field.
Task-3116125
Part-of: odoo/odoo#113538
In 49bc9aac201136e684cac9d84df97f80d217afa4, when we need operation_id
when we check if manual_consumption is readonly or not, so
groups="mrp.group_mrp_routings" was added for manual_consumption.
As a result, we can't see manual_consumption on BOM when workorder is
not enabled.
To fix, we add a computed field as a workaround.
Task-3116125
Part-of: odoo/odoo#113538
Revert partly https://github.com/odoo/odoo/commit/d55e6cca0648c78ab27e0107ab7d545e9fd4972b.
Rationale: if the field workcenter_id is not found in the group_bys, the
records in a given row can be associated with different workcenters with
different unavailabilities. So if for instance two records in the same
row are related to workcenters 1 and 2 with respective unavailabilities
from Monday to Wednesday, and Thursday to Sunday, that row would be
totally greyed. This leaves the user with no interesting information.
Moreover, we are about to refactor the GanttView and we want to simplify
the API of the method gantt_unavailability, in particular we do not want
to send row records anymore.
Part-of: odoo/odoo#112756
Co-authored-by: Mathieu Duckert-Antoine <dam@odoo.com>
Traceback happens because it doesn't require records and call the
function without row records. The code doesn't handle that case.
Don't try to find unavailabilities in that case and just skip this
part of code
closesodoo/odoo#113104
Signed-off-by: Steve Van Essche <svs@odoo.com>
When validating a confirmed picking, if in the meantime the user
added an SML with a kit, the done picking will have some not-done SM
for each kit component.
To reproduce the issue:
1. Inventory > Operation Types, edit Receipts:
- Show Detailed Operations: True
2. Create three products:
- P_kit
- P_compo
- P_other
3. Create a kit BoM
- Product: P_kit
- Components: P_compo
4. Create a planned receipt R
- Operations:
- 1 x P_other
5. Mark R as todo
6. Add two detailed operations:
- 1 x P_other
- 1 x P_kit
7. Validate R
Error: The SM for P_kit has been replaced with its component, which
is correct. However, the done quantity of the new SM is 0, it should
be 1
At some point, because the done quantity of SM_kit is gerater than
the demand, we create an extra move:
https://github.com/odoo/odoo/blob/24f2e3f73498e5eb180a6793de6c25efd414aadb/addons/stock/models/stock_move.py#L1529-L1534
So, the goal is to create a second SM_kit_02 with the expected
demand. Then, we merge this new SM_kit_02 with SM_kit:
https://github.com/odoo/odoo/blob/24f2e3f73498e5eb180a6793de6c25efd414aadb/addons/stock/models/stock_move.py#L1491-L1493https://github.com/odoo/odoo/blob/5f8da70b5b1f313e9b676846e55e84621f55e734/addons/mrp/models/stock_move.py#L239-L242
As shown above, we explode SM_kit_02 which gives SM_compo. However,
we don't explode SM_kit. Thefore, we will not be able to merge
SM_compo with SM_kit. In such situation, we should also explode
`merge_into`.
For the explode method to work with SM_kit, we need to change few
lines: as said at step 4, the receipt is not an immediate one.
However, we still have a case here where the SM has a quantity done
without any demand and only the done quantity matters (as we are
validating the receipt)
OPW-3015933
X-original-commit: 35a5b83b93fceac4073689edd74d680bed09a143
Part-of: odoo/odoo#112814
Usecase to reproduce:
- Set the warehouse as 3 steps receipt
- Put a security delay of 3 days for purchase
- Set a product with a vendor and 1 days as LT
- Replenish with the orderpoint
You expect to have a schedule date for tomorrow that contains all the
product needed in the incoming 4 days.
Currenly the internal transfer from QC -> Stock is for tomorrow (ok).
The transfer from Inpur -> QC is plan for 2 days in the past. (not ok)
The PO date is plan for 5 days in the past. (not ok)
It happens because the system check at each `stock.rule` application if
purchase is part of the route. If it's then it applies the security lead
time. It's a mistake because we should apply it only the first time.
To fix it we directly set it when the orderpoint run and not during
`stock.move` creation.
However for MTO it's not that easy. We don't want to deliver too
early the customer. So we keep applying the delay during the
`stock.move` creation but only when it goes under the warehouse stock
location.
X-original-commit: 97f52bd40d97109a7983549d252476959ddceada
Part-of: odoo/odoo#112325
When auto-fill the duration of workorders in immediate production, the
workorder cost is not included in the price of the product.
It happens becuase we calculate the price in _post_inventory but we set
the duration after _post_inventory. To fix, we set the duration of the
workorders in before _post_inventory.
closesodoo/odoo#111898
X-original-commit: 707769478b9f63319689ff2347d300ce1800d1d0
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
before this commit, the precision given for the field product_qty in mrp.bom model is Unit of Measure, which is not existing by default in Odoo decimal precisions.
after this commit, precision will be updated to default Product Unit of Measure precision
closesodoo/odoo#111115
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Necessary for odoo/enterprise#35867
Steps to reproduce:
- Install Quality, Manufacturing
- Manufacturing > Settings > Enable Work Orders
- Manufacturing Orders > Create order for Table > Confirm > Work orders
tab > Open Tablet View
- Get to step 'Please encode the table legs lot number'
- Change the quantity to produce
- Pause > Continue
Issue:
The quantity to produce is reset to 4/4 Units.
Solution:
Check if the workorder is paused before applying `qty_done` changes.
opw-3032052
closesodoo/odoo#111402
X-original-commit: 4acb1781c5aedc011ba00054285f64963aa0dacc
Related: odoo/enterprise#36491
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
yhu-odoo