Usecase to reproduce:
- Create a MO for 2 unit (1 component per finished product)
- Produce 3 units
- Mark as done
- Unlock and change the quantity to 3 units
Expected behavior:
3 components removed from stock
Current behavior:
6 components removed from stock
It happens because the set_quantity_done create a new stock.move.line
with excessive quantity. Then the write of qty_producing in
mrp.production will write this quantity on all the `stock.move.line`.
It results by moving number of sml * the new quantity producing
Solution do the write of new quantity done on the `stock.move` level
and let him manage the `stock.move.line`
closesodoo/odoo#161728
X-original-commit: fa3439e5c595a04e67fa22965d6b10bb1f487f63
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Some people want to manage the subcontractor stock the same way than a
classic stock. It will then impact the on hand value but it's the
behavior they want.
I keep the constraint on internal location since it will impact
valuation.
closesodoo/odoo#163262
X-original-commit: be8e1da9d9dc3b82479b1560c9d5e780c8ecb36b
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Usecase to reproduce:
- Product wiht a real time valuation
- Product with invoice on delivered quantity
- Create a SO for 5 units and 1000$ each
- Do a full downpayment of 100% of quotation
- Deliver 3 out of 5 units and create a backorder
- Create an invoice
- Validate the invoice
Expected behavior:
The cogs entries are there
Current behavior:
No cogs
It only happens with partial downpayment. When the downpayment amount
equals the quotation amount. An invoice is created instead of a credit
note and the process works correctly.
It happens because it creates a credit note with a negative quantity to
invoice so the system doesn't understand it has to create the cogs at
that point.
closesodoo/odoo#161768
X-original-commit: d2a365c2ee9af6a9272d83183fc75fa6914bc560
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
A lot of users don't understand why they can't reserve in MTO chain after
moving a product with an immediate transfer. It's due to the double check of
_action_assign that look where the move orig stored the product and
if the quants exist in this exact location. In our case the product was
moved so the match doesn't work.
We introduce an new parameter to check if modifying the behavior on
those cases could work. When _free_reservation is call on a
`stock.move.line`, we expect to never find it at this place
anymore (except if we bring it back). Then we drop the MTO link
for this step and use the MTS reservation.
WARNING, this parameter could remove too many mto links. e.g.
There is multiple stock.move.line linked to different locations
they will lose the link for product remaining in the same place.
closesodoo/odoo#155118
X-original-commit: af41b538d89a3c59c78f65c9174c7fbf4aa43922
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
There is 2 issues with it:
- People that want to use multiple picking type or multiple store after
manufacturing locations. It's not possible since the equals is strict
on the warehouse store after manufacturing picking type.
- The procurement group always use the default manufacture picking type
and ignore the picking type on the manufacture rule that will be use.
This commit checks if the location is a child of the post production in
order to create the procurement group. It would be an issue for people
having multiple step in post prod. But it could be fix by using a subset
of the warehouse post production location.
Check if we have a manufacture rule with the same warehouse in the
current route. It's not perfect but it could give a more accurate result than
today.
closesodoo/odoo#161690
X-original-commit: f82a0f2ea8f3c57bae915520f9e4a25b54b81ce4
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
It's not possible to push in intercompany location because the warehouse
is set base on the initial move. However in intercompany we don't
have a warehouse in the most cases.
Also there is an issue with the cache holding the route on the product
for the current company. So we invalidate it to retrieve all the routes
among the different companies
closesodoo/odoo#161717
X-original-commit: f16e0a2c954f1dce14880d62b6c07518f7317d1b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Usecase to reproduce:
- Company A Stock -> Interco -> Push to Company B stock
- Create a SO from company A with company B as customer
- Create a pull from WH/A to interco
- Create a push interco to WH/B
- Confirm the SO
Current behavior:
Wrong company on stock.move from interco to WH/B due to rule with
company A
Expected behavior:
Pushed to stock B
It happens because the rule_id is not set during the copy of push_apply.
So it just keep the same rule than the move triggering the push (WH/A ->
interco).
X-original-commit: dc58d7913131f1f4dbeb0e3337e61e0b21f6f0d9
Part-of: odoo/odoo#161717
This reverts commit 8a5541d16caa793c7549d78c082f7879d3aba233.
It's a too big change for stable. It breaks the flow for poeple
that want to be in just in time but want to consider the future
deliveries to order all at once. Due to reverted commit they see
their reorder in advance.
The fixed use case, could be achieve with the security days or the
global lead days system parameter.
opw-crl
closesodoo/odoo#158302
X-original-commit: 51833e4735fb0b761d3cd2867dfd166813469e70
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Use case:
- Create a Kit BoM with finished qty to 5 consuming 10 components
- Do a sale order for 3 units (3/5 of BoM)
- Update the sale order line to 4 units
Current behavior:
The delivery has a huge amount to deliver
Expected:
The delivery is for 8 units
It happens because the method `_compute_kit_quantities`
always expect a BoM for 1 units.
`bom_line_data['original_qty']` always contains the number of times the
BoM will be needed and not the quantity of finished products.
In order to have the number of component by unit of finished product we
have to introduce the BoM quantity in the formula
closesodoo/odoo#160149
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Usecase to reproduce:
- Create a picking with available quantity and another without
- Confirm both picking
- In list view, select the two picking and use the validate action
Expected behavior:
The first picking is validated and the second has been untouched
Current behavior:
The second picking is picked. That will prevent any further reservation
It happens because on multiple records the error message for empty
picking is bypassed and the picked is applied on it.
Close#153983closesodoo/odoo#155039
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The `test_conflict_and_replan` was not properly setup and doesn't
show the real issue when plan workorders in wrong order and use the
replan action.
.workorder_ids return base on the _order of `mrp.workorder` that is the
'leave_id, date_start, id'. However in our case, when the dependency are
not active, we want to do them in the order define on the BoM. So we
sort them before by operation sequence before defining the
`blocked_by_workorder_ids`
closesodoo/odoo#143850
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This reverts commit 652edc38527b14995f017d514053a57825091813.
It creates a new issue with valuation change.
Steps to reproduce:
-Create a new product with a cost of 10 (std, manual)
-Create an inventory adjustment to set the quantity to -3
-Change the product's category to real-time
-Now the valuation for this product is -30€, but the accounting part has 30€, creating a difference of 60€."
A better solution to fix both issues has been tried but it was far from
optimal. Since it's an edge usecase we will not support it until master
closesodoo/odoo#150112
X-original-commit: a3bae79d8102f528c4947b2231ecabe8cf907bce
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Fine tuning of #143380
It only works for stock.move but it should also be the case for
stock.move.line
closesodoo/odoo#147597
X-original-commit: b218655990137e223f8df7977ae3ac36d93a32a7
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
In 16.2, this commit https://github.com/odoo/odoo/commit/b0a6c525b06fabf8cf869890d8383f8304bae697
modified products' domain on a manufacturing order.
The domain added was not correct as it overrided the domain from
stock_move instead of doing the intersection of the two domains.
task_id: 3630626
closesodoo/odoo#148208
X-original-commit: aedbbae168612a8ea3a2df5cb855432cf3001d26
Signed-off-by: Steve Van Essche <svs@odoo.com>
When replenishing a product with a route buy selected on the product form but no vendor
added, we fall into an endless loop because the default_get sets the route,
which triggers the onchange that return a warning.
This will again call the default_get and the loop never ends.
The onchange is useless as it's only goal is to display the warning, and as the field is
required on the form, the user will not be able to submit it.
opw-3653714
closesodoo/odoo#148201
X-original-commit: e7fca1c849652920388526f4797397aa18247204
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
In a Manufacturing Order based on a BoM, changing the qty values
and then change the scheduled date will reset the qty to the bom ones.
This should not be the case.
Regarding the test, setting the date before the bom_id ensure that the date will
be set when we enter the _compute_move_raw_ids.
enterprise: https://github.com/odoo/enterprise/pull/51822
opw-3568943
closesodoo/odoo#146508
X-original-commit: 780dded
Related: odoo/enterprise#52892
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Usecase to reproduce:
- Install purchase and mrp
- On a product set both routes manufacture and buy
- Create a BoM for the product and define a seller
- Sell a unit
- Open the replenishment. Buy or manufacture is set as route
- Go to the settings and set the route not sellected to the smallest
sequence
- Delete the orderpoint and open the replenishment menu again.
Expected behavior:
The new route with smallest sequence is selected
Current behavior:
The same rule is selected and the order used by _get_rule and to
compute the lead time is bypass
It happens because both override of the method are at the same level
(super of stock) and are call arbitrary one before the other.
In order to fix it uses rule_ids that was computed before calling the
function and it contains the real rules used to compute the lead time
closesodoo/odoo#146051
X-original-commit: cad38a349c3486cb199ef8079bdd46cffefd5b2e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit adds tests for the computation of the date of
the replenishment wizard.
Taken into account for the date computation:
- vendor lead time
- days to purchase
- security days for purchase
- security days for mrp
- rule lead time
task-3527727
Part-of: odoo/odoo#145384
The previous delay showed in the replenishement wizard did not take
the following delays into account:
- vendor lead time
- days to purchase
- security days for purchase
- security days for mrp
- rule lead time
- manufacturing lead time (BoM)
- days to prepare manufacturing order (BoM)
Made the vendor delay visible by default in the vendor search view
Also changed function orders in stock/product_replenish as it
did not follow the guidelines
task-3527727
Part-of: odoo/odoo#145384
The show vendor button creates an orderpoint.
This commit removes it as it should not create one.
The wizard will be adapted in a future master pr.
task-3527727
Part-of: odoo/odoo#145384
In 16.4, this commit https://github.com/odoo/odoo/commit/c3b7a87462cd41654d0e2bd3beb2f0e065ddfb75
created a notification when replenishing a product.
However, it achieved it by modifying a stock.order_point which was
not the ideal solution as we don't want the order_point to change.
In this commit, we will revert to the previous behaviour,
but we'll keep the notification by delegating it to the wizard itself.
The way the record created were retreived (to display the notification)
was thanks to the orderpoint.
As we do not have access to orderpoints now, we are just retreive
the first record (of a certain type) created just after the start
of the function.
This method has a big problem : concurrencies.
If anyone creates a record on ``manufacturing.order``,
``purchase.order.line`` or ``stock.move`` between the start of
our timer and the creation of our record, a wrong record will be
selected.
task-3527727
Part-of: odoo/odoo#145384
1) Create + Confirm two MO's for product
2) Merge Confirmed MO's together
3) Mark MO as Done
4) Press Apply on Immediate Production
4a) Stops consumption due to no Components being declared
4b) Would expect the Consumption Warning Wizard to be triggered here to allow use of "Validate & Set Quantities" button
It happens due to #85301 the purpose was to avoid the rules from
stock.move. However for other functionalities of MO like manual
consumption. We would like to keep the standard behavior.
Call the classic action_confirm but after manualy updated the stock.move
opw-3577267
closesodoo/odoo#144350
X-original-commit: dcf13fd1127436abb3c6a5f225f8f99d571330a3
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
What are the steps to reproduce your issue?
Price Decimal Precision set at 5, currency at 2. Anglosaxon enabled.
Have a product with a unit / purchase cost of 3.30125
Create Purchase for 1500.00 and receipt in.
This creates an SVL and AML for 4951.88
Create Bill with unit cost of 3.30125 and total amount of 4951.88
Confirm Invoice
What is the current behavior that you observe?
The layer unit price value is calculated unrounded (line 304, purchase_stock/models/account_move_line.py) - so 4951.88 / 1500 = 3.30125333333.
This is then subtracted from the Invoice unit price leaving a difference of 0.00000333333
Despite the price_unit difference being less than the precision this then multiplies out to be 0.005 that gets rounded to 0.01.
A new SVL layer is created, and a new move valued at 0.01 and remaining value on existing correct layer is reduced by 1c.
When anglosaxon attempts to reconcile the various moves, it is unable to because there is now a 1c difference in the sum of the relevant AML's.
What would be your expected behavior in this case?
Not to create useless SVL that is wrong
Reconcile anglosaxon records normally.
It happens due to the comparaison between the layer price unit that
is not rounded and the price unit of the account.move.line that is
rounded to the decimal accuracy. We want to keep the most accurate
value so we modify _get_gross_price unit to recompute the unit price
this way we ignore the rounding
close#140410closesodoo/odoo#143768
X-original-commit: 73aaaa9550b15225e25fcd750ebfd5fb58436064
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Currently there is 2 behaviors:
- The records is pass to the _gather function, it will order base
on location complete name
- The records is not pass to _gather, it will be order by id.
Obviously we never want to order by id because it's not configurable
and hard to undersand since id are not editable
closesodoo/odoo#142237
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Only keep the forecast widget since it does the same with more data.
There's no point in showing the forecast for done or cancelled
production orders.
The purpose is to have an easy view at the beginning. Avoid to
add too much useless information for users
Also put it at the end so it's the same standard for
stock/mrp/repair
closesodoo/odoo#140955
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The on_hand filter is used from the product.product stat button.
It's dangerous to modify it because the quantity with the filter
would be different than the ones in the stat button.
closesodoo/odoo#141272
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
It's not possible to copy paste in the lot_name directly. It has been
remove since the import button.
Also add by default a search on hand in the quant view from the
stock.move.line. We don't want to show quant already send to customer
location or without quantity
Part-of: odoo/odoo#141272
Temporary fix to revert once it will be done correctly on
client side. The idea is to remove the variable after a record
editation in order to trigger the recompute of column width
closesodoo/odoo#140663
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Currently after confirmation on picking. The details operations button
is mixed in the trash icon. The view needs a refresh to be correct.
This is cleaned by moving all the buttons together and introducing the
custom column before the last buttons group.
Part-of: odoo/odoo#140663
When validating a draft transfer. Currently it says that we don't
have quantity. So when validating a draft, set the quantity to
initial demand and validate
Also, if a move is created through RPC with a quantity, auto-confirm the
move, regardless of its initial demand.
closesodoo/odoo#140578
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
It adds advanced data on the picking view.
It's not needed by default so we hide it
closesodoo/odoo#140577
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This commit fixes:
- hide `read_duration` and `expected_duration` in MO list view.
- hide `component availability` byt default in bom overview,
unless if coming from mrp forecast.
task-3547356
closesodoo/odoo#140244
Related: odoo/enterprise#49802
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Since PR #137864
We do not have quantity done anymore and we use the picked field
to know if something is picked or not. But we remove the immediate
transfer wizard and we consider instead than if nothing is mark as
pick, everything is pick. We will do the same for repair because it
would confusing to have a different behavior
closesodoo/odoo#140322
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
There is a button in the header to register subcontracting process
(when needed). And there is an additional button in the view with
the purpose to correct data later after the encoding. However we
can't set button with optional="hide". We rename it with an edit
icon
Part-of: odoo/odoo#140307
Replace the warning by a usererror. That way it rollbacks to the
previous quantity. It will avoid to fake the user thinking he could
bypass the warning and remove the quantity silently later.
closesodoo/odoo#140172
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Changing the destination location on a picking will:
- Change the dest location of its stock.move
- Not change the dest location of stock.move.line
So it the picking has been reserved, everything will
be send to an incorrect location. On top of it, the
system prevent to select a destination location that
is not a child of the move dest location.
This commit, redirect the location dest on stock.move.line
when the dest location on stock.move change.
closesodoo/odoo#140101
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Currently when you fill quantity on the stock.move and directly click on the details operation button,
you will see move lines based on initial quantity.
It happens due to the inverse of quantity on stock.move that is only trigger on the save (expected).
But in our case, we want to do a save before opening the stock.move.line to have something according to the quantity.
We also only trigger the save when the quantity has been change and the stock.move is open.
+ Hide quantity in draft
closesodoo/odoo#140059
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In the quotation, using the tab key when the qty at date widget
is invisible was not working as the tabindex was invisible as well.
task-3201527
Sub-task: 8
Part-of: odoo/odoo#127409
The rational is:
Currently we have 2 columns. One for reservation, the other
for quantity picked.
However in real time, either you follow the reservation and everything
goes well. Otherwise you pick something else. In the case where you
pick somewhere else than reserved, you would like to modify the
reservation to have something similar and free the quantity you
didn't pick and expect the system to not suggest the ones you took.
In other hand, we always want to have the reserve quantity similar to
the done.
On top, having two columns could be confusing for the end user.
The cons:
-The qty_done column could be use during the picking, to
remember if something has been pick or still to pick.
- For some flow (put in pack), it's easier to write a part of the quantity to pack
and still want to reserve the full amount of product.
We goes back and choose a ligther interface over complex feature.
Changes:
Qty done and reserved qty are merged into a single column.
A new checkbox on the move exists to mark it as picked or not
Since the reservation always follow the quantity, it's now possible
to have more reserved quantity than stock. However the system will
never propose it and the inventory showing reserved > quantity should
be a warning.
The system should never modify a move that has been picked. We don't
want to overide the user action.
Regression:
Not able to pick a single stock.move.line
closesodoo/odoo#137864
Related: odoo/enterprise#48709
Related: odoo/upgrade#5310
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
As mentioned in https://github.com/odoo/odoo/pull/105848#discussion_r1324796532, the ``_getCurrentLocation`` method was called on every page of ecommerce, while it was doing nothing unless if we are on the payement page.
Putting the call in the ``if`` ensures that there are carriers on the page and thus calls it only when on the payment page.
closesodoo/odoo#139086
X-original-commit: 65e7535fc9392e7b9355a31fa8f7c8abc1e3518f
Signed-off-by: Martin Maes (marm) <marm@odoo.com>
On stock.move, the icon next to the reservation to open the forecast view is
not align with the text.
closesodoo/odoo#137560
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
This reverts commit 656d8ace87.
The rational was: "If people don't have inventory, they will need a
backorder anyway and it's logical to not display the popup even
if the picking type has 'ask' for create backorder".
Also for the barcode application in OE we only show the reserved lines and
you could have the message if the picking was not fully reserve. Even if
you completed all the lines. So we could have a single flow for backend
and frontend.
But it's difficult for poeple to understand that the backorder is
base on the reservation and not on the initial demand. So we do a
step back. On top of it, people usualy won't mix flow. So they
could totaly use the "always create a BO" option on picking type
when they use the barcode and "ask" when they use the backend.
closesodoo/odoo#136725
X-original-commit: ed291c4d47783c5912ffb40db7893c321ccdb1e2
Related: odoo/enterprise#47959
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
commit [1] addeed production cost account. However this account is
mandatory with real time valuation. It could be an issue during
production because we don't have an automatic way to create a new
valid account. On top of it this behavior is optional and people
could still use the classical input and output account for production.
This commit make the cost of production account optional and fallback
on previous behavior with input/output accounts
[1] commit 1eb2e7c814closesodoo/odoo#136463
X-original-commit: ea647812e76931f9193ae841f428b312b861739b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Usecase:
- Create a BoM for a template
- Replenish 2 different variant
Expected result:
2 distinct production orders for each product
Current result:
A signle production order with the first product variant and twice the
quantity
closesodoo/odoo#134067
X-original-commit: 2a658fb4a509238cd1462e2ffb615ecec05bc2e2
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Following commit 5620e47f80
1. workcenter automatic setting should be in demo data
2. Routings in demo data where set to active=False and enable
in mrp_workorder (OE) module. Since we enable by default
workcenters in mrp, we could remove this restriction
closesodoo/odoo#133908
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
When opening the list view of workorders, a traceback was triggered.
The problem was that parent was not defined when not in a view form.
Checking if parent first exists solves the problem
closesodoo/odoo#133213
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Creates a sale order, then validates the delivery.
Modify the sale order lines qty via import.
We expect a new delivery instead we have a UserError
The purpose of the userError is to avoid editing
reserved quantity directly in the picking. But in
SO/PO case it's handle by the system and quantities
are correctly reserved so the UserError should not
happens.
Remove the basic constraint on stock since it should not
be an issue anymore
opw-3336131
closesodoo/odoo#130870
X-original-commit: 87f62c90e703049bde8676663851a98e3b19f9db
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Shop floor app is base on employee. When hr_attendance is install,
it will lock the app until the user unlock it with the pin. For
demo purpose it's blocking the flow and it's not intuitive
closesodoo/odoo#131707
X-original-commit: b4ec72d0079ae43ace40dbc9ec0fd1b686e125a4
Related: odoo/enterprise#45699
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
We only show the move that requires a manual operation in the
shop floor application. Currently we only see the MO for table top
with a single operation to register the finished serial.
It's a bit funnier to see also the components required and check them
Also the manual_consumption field is a compute store without inverse.
It means it's readonly true by default. But we should be able to pass
a value and use it instead of the compute
X-original-commit: 58118291e148a144058c0c883ddd138187a86f3d
Part-of: odoo/odoo#131707
Before [1] the demo user only has the basic right. Now it has
the administrator rights and it prevent an easy testing for user
flow.
The demo and admin users get their rights from the common
template with administrator right everywhere. Since it's a
data, we could just remove the administrator level and set
the user level in the demo data.
[1] commit 121cd0d608
X-original-commit: 7b7fdf5d4eb892bfd3c2fdb575264025dca21ca5
Part-of: odoo/odoo#131707
During the test, the rate are created on UTC timezone.
However the test could be run with a different timezone.
Since the rate doens't have a name, by default they have the
create date name. However due to timezone difference, it could
be different day and the newly created rate for the test will be
filter out
closesodoo/odoo#131708
X-original-commit: 300fe8ad36163b6ad7f8a37ac26b014c1510d64f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Usecase to reproduce:
- Set operation time base on last workorder
- Create 2 MO
- On first MO, set 15min as duration
- On second MO, set 10min as duration
- Validate both MO at the same time
- The duraction expected on the operation could be now 10 or 15min
It happens because the search in the compute is only base on date.
And when both MO are validated at the same time, it's not enough
closesodoo/odoo#131307
X-original-commit: cad75ac78b61046352c39d3f3b7717cfbad42c8b
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
**Sum of timesheets time different than what the timer displays**
Steps to reproduce:
1. Start a workorder timesheet, then stop it
2. Repeat the process multiple times.
Current behavior:
The error is based on a microsecond precision so you could need
to try multiple times before reaching the problem.
- The time displayed on the timer widget does not display the same as
the sum in the timesheet list.
- The difference between the start date and end date of a timesheet
is not always equal to its duration.
Expected behavior:
- The sum of duration should be the same as the one displayed on the
timer widget.
- The difference between the start and end date of a timesheet
should be equal to it's duration.
The computation of the duration of a timesheet will take microseconds
into account. It's not useful in the timsheets to save microseconds
as the precision is too high and as the user cannot change it manually
anyway.
Removing this precision (i.e. setting microseconds to 0) solve this
problem as it does not trigger rounding errors in a single timesheet
and thus in the total computation of duration of a workorder.
Also, there was a precision rounding error on the timer widget.
Time is saved as minutes in db, and displayed as seconds.
So 2s is 1/30 of min => 0,0333... min.
As multiplying this by 60 will return 1,99999 and as the timer was flooring the result,
there was some difference between the time recorded and the value displayed in the
widget.
enterprise : https://github.com/odoo/enterprise/pull/41727
opw-3241156
closesodoo/odoo#130618
X-original-commit: 0172395fa60c94150609bbbfe174d5eee44525fe
Related: odoo/enterprise#45109
Signed-off-by: Tiffany Chang <tic@odoo.com>
In `mrp_workorder` (enterprise), we're adding a new view to process
manufacture orders and workorders: MES.
These changes are more or less related to MES. See following for the
main changes.
== Be able to mass produce an ongoing production order ==
Currently once the mo is in progress it's not possible to use
the mass produce feature anymore. Even in basic cases where the
componenets are not tracked. It's also not possible to mark
all the productions directly as done. It's needed in the
mrp display action, so we enable it everywhere
== Manage different flows with tracking ==
Currently there is 2 different flows:
- No tracking -> All the quantities easy
- Lot -> All the quantities + display button to create lot number
- Serial with component not tracked or only one: Mass produce
- Serial that require a match between components SN/Lot and finished
product serial number -> Only display it as one unit with an automatic
backorder/
task-3231200
Part-of: odoo/odoo#127250
Co-authored-by: R1D1CUL0US <clpi@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Following #127245
It happens because `_should_bypass_reservation` has been removed in 15.0
and only exist on the `stock.move` object and not the `stock.move.line`
anymore
opw-3336131
closesodoo/odoo#129076
X-original-commit: 7e917e8713e246811531f9d7c90395242e544057
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Usecase to reproduce:
- Create and validate a PO + receipt
- Import a file containing a different PO line quantity
Expected behavior:
The PO line is modified and the receipt has the a new move
Current behavior:
UserError asking to modify the quantity done of stock.move.line instead
reserved quantity.
Following commit 76ad7b7dedab3c504c9231359b07d01505d0cc0e
The purpose is to block import with reserved quantity
It happens because the PO line import trigger the creation of a new
stock.move and reserve it (create the stock.move.line). However since
it's created by the system the data are correct.
There is no issue in multiple step since the internal step requires
the move_orig_ids and thus the product_uom_qty is empty
To fix it:
- Relax the constraint to only consider sml having an impact on quant
opw-3336131
closesodoo/odoo#128157
X-original-commit: a755db18981f23f031fdf21b58b309e3210df262
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Usecase to reproduce:
- Set reservation method to closest location
- Set the POS as real time stock
- Put 1 unit in A and 1 unit in location B
- Create a SO for 1 unit
- Sell it in the POS
Expected behavior:
The unit has been taken from the reservation in location A
Current behavior:
The unit is taken from B
It happens because the SO is unreserved after the new picking
and stock.move.line creation. Since the unit is reserved, he
can't pick it and take a random ones.
The solution here is to unreserve the related stock.move to
free the reserved unit, it will not always be the same than the
SO but it will consider it in the removal strategy. It could
also fix the case where only 1 unit remains in stock and he won't
pick it.
opw-3271217
closesodoo/odoo#126818
X-original-commit: 312cf1870d15145b511e4ebffa82dd44a7fec22c
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Traceback due to variable quant not instanciate during import.
It's due to commit a381b6fdd19d4f1a4512efe4f4877c50b5fd453e
closesodoo/odoo#126912
X-original-commit: 10e9e66b275649ef36880f4b7a6fbd4c3dc739d9
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
product variable used in the rounding precision come from the upper
loop and won't work for all the quantites.
opw-3229080
closesodoo/odoo#126144
X-original-commit: cf68853573f70f8dfa84a15ef515479142705a38
Signed-off-by: Tiffany Chang <tic@odoo.com>
Follow the same behavior than project. Only import the code for the
views. It's not a good idea to import all the backend since it's not
needed and it could cause issue with extra features
closesodoo/odoo#121669closesodoo/odoo#119040
X-original-commit: 8f3f10731545f32d283772fc009733c1b43f536b
Related: odoo/enterprise#41188
Related: odoo/enterprise#39987
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In https://github.com/odoo/odoo/pull/123074, the fix done did not take the formatting of numbers
bigger (or equal) than 1000 into account.
For example, 1000 become "1.000,00" and parsing it again will return a 1.
To fix this, simply modified the thousandsSep to an empty array
closesodoo/odoo#125784
X-original-commit: c8a738610778d110734ca5b9b9cfe8723f70f8ce
Signed-off-by: Steve Van Essche <svs@odoo.com>
Use case:
It happens that a product is consumed in different operations.
So it needs two distinct BoM lines. Since commit [1] the stock.move
in pbm are not merged. However [1] was design for kit.
In our case we would like to have only one stock.move for all the
quantities.
The fix is not perfect because it won't work if we confirm at the
same time a move with a kit and without it. But at least it will let
people using MO without kit has the correct behavior
+ remove a duplicate of the function
[1] commit 741d2fe9efclosesodoo/odoo#125778
X-original-commit: f74149017ca41720a69179e3f5068f530b037341
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Usecase:
- Create a picking and a move without quantity
- Click or the show detail or save
The picking goes into the state draft while it shouldn't.
It happens because when a quantity done is set, it will
goes to process_increase that will assign the move. With
0 qty, it's not assign and stay in draft (default value)
The picking state is then computed based on the move state.
To fix it, force the state to assign on stock.move in immediate
transfer without quantity.
Part-of: odoo/odoo#122445
It takes 70s to generate a receipt with 2000 serial numbers.
It happens because during the first part of the loop
(model `stock.move.line` in the `create` method).
It will update the initial demand of the move based on the new
stock.move.line and their qty_done.
Writing the initial demand of the `stock.move` will try to reassign
it (useless in our case) and rewrite the same value on its state's field.
The consequence is the invalidation of the field on
the `stock.move.line` because it's a related to the `stock.move`.
In the second part of the loop, it check the sml state. Since it
was invalidate upper, it recompute it. That prevent a correct prefetch
and cause a performance issue.
We fix it by writing only once the information by move. And it
prevent the recompute later since the state is not write during the
loop.
closesodoo/odoo#122651
X-original-commit: 9dbc374fb89550444fc6f1c9445cb57067af214c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Use case: Create an import file for a picking with stock.move.line
directly in it and add some reserved quantity on the stock.move.line.
The import of stock.move.line is not possible directly via a
stock.move.line menu but it still possible on a picking or
mrp.production import. However the create does not expect that and never
reserve the quants. So it result with quant <-> sml inconcistencies in
the data and the error can not reserve more than you have in stock.
opw-3277938
closesodoo/odoo#122156
X-original-commit: 3e78316a51f2cb8d347af1b87abcdcb775107115
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When overviewing a BoM with a "kit" type and with no route,
the availability was always unavailable, wich is wrong if all the parts
are in stock or can be replenished.
Task-3184663
closesodoo/odoo#121783
X-original-commit: f13b4d1ae8c12a1668222e6994dea26a27c6f5d4
Related: odoo/enterprise#41248
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit merges BoM overview's lines if they are about a same component.
Before this commit, if the BoM divided it's same components to use them
in different steps, the overview would separate them as well, which is wrong.
Task-3184663
X-original-commit: 37ac2e603f332dee1c4c18a105f070cb4ae9eda6
Part-of: odoo/odoo#121783
Added the possibility to search among variants in the BoM Overview view
Task-3184663
X-original-commit: 1c636b5119a40fc9e92174027495b63fa1cafa31
Part-of: odoo/odoo#121783
Minor visual improvement for the BoM Overview printing document
Task-3184663
X-original-commit: 9e01083e605a0b91558e2b3c525bfbdae06ca91c
Part-of: odoo/odoo#121783
To reproduce this bug, you need to create a RFQ, add a product with
variants and click on the button to view the quantity forecast.
Then, click on Manufacturing forecast. The BoM overview does not
have the correct variant selected in the Select.
To fix this, simply added an active_product_id to the context, used it
to get the correct BoM data ans then display it in the select.
Task-3184663
X-original-commit: a4ab49d5e41debfe6b2d46840dfffe1008f0f1ec
Part-of: odoo/odoo#121783
Usecase to reproduce:
- Set the currencies as 1€ = 2$ ($ as company currency)
- Create a PO for a product in AVCO auto with a price of 100€
- Do the receipt
- Change the rate as 1€ = 4$
- Bill the PO
Expected behavior:
- One correction account.move.line for the 200$ and the stock
interim receipt account reconciled.
Current behavior:
- An aml from the price difference with the 200$
- Another from the currency exchange also for 200$
- The line from the price diff is not reconcile
`_stock_account_anglo_saxon_reconcile_valuation` should never reconcile
account.move.line from a price difference correction without the context
key no_exchange_difference because the currency correction is already
handle in the correction layer.
closesodoo/odoo#120158
X-original-commit: b8bbd7e2a3f8f9e119b11314bcebfadb2ba75eda
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
test_reordering_rule_1 try to ressuply 10 from RR.
However since 15.0 the picking `action_confirm` will
launch himself the required orderpoints to order the
missing quantity. So the run scheduler is useless but
should not order the quantity again since it's already
process.
But in the test the cache for the orderpoint is not
always consistent with the data. It happens that the
quantity forecast remains -10 even after the RFQ creation.
It happens due to the savepoint. It will flush the data
and take a random env. However in the enviroment, the
active_test key could be there. And it will recompute
all the fields. So it goes through `_compute_rules` that
call `search_rule`. There is an archived route from supplier
to stock. So it will pick this rule instead of the buy route.
`_compute_lead_days` will not have the supplier delay as
a result and a wrong forecasted date. `_compute_quantities`
on product will check the virtual available for this date and
will only have the out move and not the in since the domain
is incorrect with the wrong lead days date...
I can't do much since it's due to the orm.
- Remove the savepoint but it will require a global refactoring
- Fix the ORM, it's planned but difficult.
So for now I just remove the context key form the context in the
compute.
Note: this could happens outside the test when there is more than
1000 RR.
closesodoo/odoo#121106
Signed-off-by: Tiffany Chang <tic@odoo.com>
This pr fixes a bug where a validation error occurs in the timesheet
wizard.
Indeed, when the user enter manually a start or end date in a workorder,
the whole MO becomes "plan".
The problem here was that if the user opens the wizard of another
workorder (on the same MO) that has no start/ end date set, and then if
he saves (no matter if he changed something), it will trigger a
validation error because the start and end date of the workorder is
required in that view if the MO is planned.
closesodoo/odoo#120386
X-original-commit: c9728858aa46e6cb1a3d39cbc8da8e175007e456
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
On the manufacturing order, modifying the timer value does save it's value
in db but does not actualise it in the front.
The "rerun" condition is already checked in MrpTimer and does not need
to be checked in MrpTimerField
closesodoo/odoo#120385
X-original-commit: a8cfa1d26ef84aa6690d3cfa8b98b6cecf4f27d9
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Use case to reproduce:
- Set "receive good in input and then stock" on the warehouse.
- Set two suppliers on a product. one from a partner (higher priority)
and one from a child partner (lower priority).
- Set the child partner as the vendor on the replenishment report.
- Order a replenishment for the product.
It happens due to an hack that use a field on `stock.move` in order
to temporaly store the partner among the moves until the RFQ.
But this field is a many2one on `res.partner` model and not on
`product.supplierinfo`
`_run_buy` receive a partner and still use `_select_seller` with the
partner in order to find the best pricelist. But it won't use the
specific supplier price list set on the orderpoint.
In order to fix, we don't store anymore the price list partner on the
intermediate move. In run_buy we receive the orderpoint if it's the
origin of the procurement. On the orderpoint the supplierinfo is set.
So we take it from there.
opw-3180945
closesodoo/odoo#119063
X-original-commit: 3cd5b9b7688ef7e6c6fa4fce1c0ad319fb577745
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit fix a traceback when printing the repair quotation
using the DIN 5008 repair module.
The field updated was not the correct one
task id : 3178931
closesodoo/odoo#115454
X-original-commit: 008cd881abcc9856de8bd7a7a8a5382fc31dc272
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
No need a common file for 3 tests. On top of it contains
global variable and a lot of indirection, making it impossible
to read.
Also before the quant reservation commit, a savepoint was call
during the action_assign and trigger a flush and recompute all.
Since it has been remove, it's computed during the first read on
it, that's during the mark as done and since the MO state is not
draft it will keep the default value (False). Call it after create
to trigger the computation at the right time.
+ a bit of linting
closesodoo/odoo#115328
Related: odoo/enterprise#38207
Signed-off-by: William Henrotin (whe) <whe@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
The 'To do' picking filter made no sense as it used to check the pickings
that are not assigned or assigned to the user.
The new behavior corrects it by checking if the previously selected pickings
are not in a 'done' or 'cancel' state.
task id : 3087740
closesodoo/odoo#111648
Signed-off-by: Steve Van Essche <svs@odoo.com>
Kit were not reconcile because the `_stock_account_anglo_saxon_reconcile_valuation`
method try to match `account.move.line` and `stock.move` base on the
product field. However in kit case, the moves are exploded in mutliple
moves containing the kit's components. Due to that the matching is not
made.
To fix this issue we use the `purchase.order.line` that is share between
the `stock.move` and `account.move.line` to retrieve them.
closesodoo/odoo#114987
X-original-commit: f594c837c8a347abb48015d4e9bb0d5109228539
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
-Create 3 products with different costing methods: AVCO, FIFO, Standard
-Create a PO for the 3 items (same quantity and unit price in every line)
-Receive
-Create Vendor Bill
-Check Journal items.
You will notice that the AVCO product is marked as partially matched. Please keep
in mind that this only happens when the 3 costings are used and the unit price
is the same.
It happes because `_get_all_related_aml` returns all the
`account.move.line` for the journal entry and invoice.
But not only for the current product. So if they share the same
price unit then it could reconcile lines for different products.
X-original-commit: 23ccf2c1bde84f03aaaedb206e37a35de701da5e
Part-of: odoo/odoo#114987
Usecase to reproduce:
-2 products setup as Periodic valuation
- Create a PO to buy both products
- Receipt and create the bill
- Modify the price unit on both invoice line to create correction layers
The label on the journal items have the same label relative to only one
of the products. It should keep the same label than before the
confirmation.
closesodoo/odoo#114792
X-original-commit: 226ae25b5f93164f14c1e68ed8bc2ea8a48b4e27
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Removed the margin on rate when the provider is Fixed Price
Removed the margin on rate, free, amount when the provider is Based on Rules
Added a fixed margin for all the other providers
task-3043063
closesodoo/odoo#108794
Signed-off-by: Steve Van Essche <svs@odoo.com>
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>
Arnold Moyaux