Currently on stock moves, product_uom_qty indicates the demand qty
before the move is done and it indicates the acutual done qty when
the move is done.
As a result, when validate a stock move with qty_done !=
product_uom_qty, a new move is always created for the difference.
And the product_uom_qty of the original move will be changed to match
qty_done.
In this commit, we change to that product_uom_qty will always indicate
the demand qty, and qty_done will always indicate actually done
quantity.
To do that, when underconsumption, we won't split the move when no
backorder. and when overconsumption, we will always merge the extra move
back to the original move.
Task-2695732
Part-of: odoo/odoo#130342
These changes are made as a result of simplifying attrs and 'states' in
views. However, they should have remained in a separate commit. When
applying the script making the xml changes (used later for the migration
script), the script checked the definition of the python fields in order
to convert the information into a python expression. Therefore, this
commit is not applied when the script is applied to xml changes.
During this attribute deletion pre-existing errors were found. Part of
the code was using the boolean values of 'states' and another part of
the code was not. The behavior could therefore be different (in cases
where readonly on the field had the same value as the ballan in
'states').
Following the deletion of 'states' and without the application of the
view migration, the js tests (tower) were no longer functional. Tests
using the Form view suffered the same effect. There are few tests that
had to be adapted, including two tests in business accounting (updated
by the accounting team). A test for column_invisible did not work. Test
checking if the test system triggers an error if we try to write on an
invisible field. It turns out that Form was testing on the value of
invisible but not taking into account if the column was invisible. The
test system fix is applied separately because there were a lot of tests
that were incorrect.
Part-of: odoo/odoo#104741
With this commit
================
Removed 'action_mass_start' and 'action_mass_pause' methods also
the 'button_start' and 'button_pending' methods have been modified
to accommodate multiple work orders, ensuring seamless functionality.
closesodoo/odoo#130663
Related: odoo/enterprise#45883
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Before this commit
==================
Marking multiple work-orders as done was not functioning as expected.
Only the first work-order status was being marked as done, and not all of them.
Steps to Produce
================
- Create a bom product having multiple work-orders.
- Create a MO and confirm it.
- Inside WO list view select multiple work orders of the recently created MO,
and click on "done". You will notice that even though multiple work-orders
were selected, only the first work-order status is changed to "done".
With this commit
================
On selecting multiple work-orders and triggering "done" will work as expected,
and the status of all selected work-orders will be marked as "done".
Task: 3374990
X-original-commit: 486aab5ee8ae1cd8792bc9bbb4aae1797c38fe5f
Part-of: odoo/odoo#130663
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
Previous fix c7616df enforced an order on the workorders for the
computation of the time_cycle. However, 'asc' is used by default in
order clauses if not explicitly written.
This resulted in using the oldest workorder instead of the newest to
compute the duration.
closesodoo/odoo#131830
X-original-commit: a69d13abbc81b36aaf717f8e4d665fda8580c1fc
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
When user uninstall the module 'Manufacturing' the relevant records are not
deleted from the Operation Types, Transfers and Stock Rules.
To produce in sass-16.2:
- Install 'Manufacturing' module
- Create mrp order and validate it.
- Now uninstall 'Manufacturing' module.
- Operation Type 'Manufactuing' is still showing. (14.0 to master)
- Go to 'Inventory' and click on 'Receipts' and remove all the filters.
- Another way > Create a new 'stock.picking' with 'Operation Type' as
'Manufacturing'
Error: A traceback appears: 'Wrong value for stock.picking.picking_type_code:
Manufacturing'
Fixed this issue by updating the code of the picking type and archiving it after
uninstallation of module using 'ondelete' function.
sentry-4167898386
task-3318858
closesodoo/odoo#131725
X-original-commit: 0b400d33ed9ad15d539306ff7ba8519afc63234c
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>
Before this commit
==================
Marking an operation as done rather than start and done, the status of
subsequent immediate next linked work orders is not updated properly inside
WO list view.
Steps to Reproduce
==================
- Create a bom product having more than one operations.
- Create a MO and confirm it.
- Inside WO list view select a single first operation of the recently created
MO, and click on done, you will find that the status of subsequent operation
(immediate next) is not updated properly.
This happens because of the reservation state of the MO which has initial
state as false and thus the status of work-order changes to 'waiting'.
With this commit
================
Marking operation as done the status of subsequent linked work order gets
updated properly.
closesodoo/odoo#128881
Task: 3358125
X-original-commit: 0533577264413934179cc32e0cfe26cb324dd58a
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
-Create a product in kg as storable.
-Add it into the BOM of another as grams.
-Create an MO with the BOM with more than 1 quantity to be produced.
-Set the quantity to be produced to 1, validate and create backorder.
Bug:
Error message: "It is not possible to reserve more products of test kg
than you have in stock."
Fix:
correct conversion of units during backorder reservation of component
closesodoo/odoo#129152
X-original-commit: 8f26839998f21e521ecaeba38a2bcc6c72894f41
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
The `mrp.production` method `_pre_button_mark_done` will now be public
so it can be called since the web client.
This change is done in order to know if trying to mark as done a
production will return a wizard or not, which is needed in the new MRP
Display view since there is a delay before a MO is actually marked as
done and we don't want to see the wizard poping up after this delay but
before !
The method `_set_qty_producing` public is also public now because it's
called in `_onchange_producing` but saddly, the onchanges don't happen
in the MES view, so this way we can manually call it when needed.
task-3231200
Part-of: odoo/odoo#127250
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>
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Step to produce:
=================
- Create MO of serial tracking product.
- Start workorder.
- Click on continue consumption button.
- Enter quantity to consume then click on validate button.
- Then when we click on Continue button quantity become zero or negative.
Issue:
========
If the product tracking is serial and quantity is already set to 1 in this case
it write the same 1 value in serial tracking order because of that it calls
'_update_component_quantity' method again it will make the quantity zero.
After this commit:
=====================
Prevent the quantity becoming zero.
Task id: 3212121
closesodoo/odoo#128665
X-original-commit: 907129be7efba2a0b68f9bef14c6a22c1be8861a
Related: odoo/enterprise#44183
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Create a storable product "P1":
- Unit of measure: KG
- Bill of Materials for 1 "g" of "P1":
- Component: 1 unit of "C1"
- Route: Manufacture
- reordering rule: Min 0, Max 0
- Create a Sales Order with 510 g of "P1" and confirm it.
- A Manufacturing Order for 510 g of "P1" will be created.
- Create a second SO with 510 g of "P1" and confirm it.
Problem:
The quantity in the MO will be updated to 1.02 g of P1 instead of 1020g
"Whenever we update the quantity, the `_run_manufacture` function is
triggered. Consequently, we use the `product_uom_qty` from the
manufacturing order to calculate the remaining quantity. However,
this field is computed, and it converts the quantity into the unit of
measure of the product, rather than that of the manufacturing order.
https://github.com/odoo/odoo/blob/3b801a6d48f1feffd1b87a7d54731ab58e8d63e9/addons/mrp/models/stock_rule.py#L75https://github.com/odoo/odoo/blob/5118d248ccf16fe4d2703c2a64e0267f783a56d1/addons/mrp/models/mrp_production.py#L171-L172
Opw-3410254
closesodoo/odoo#128776
X-original-commit: 04371c0ec777cede50e940f45064f86cb4cb8964
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
When user not seleted 'work center' and only selecting 'Scheduled Start
Date' and 'Scheduled End Date' while creating 'work_order' in
'mrp_production', this traceback raises.
To reproduce the issue:
1. Install 'mrp'
2. Activate 'Work Orders' in configuration/settings
3. Go to menuitem/operation and create 'Manufacturing Orders'
4. Select any product and add a line in Work Orders
5. Give values to 'Scheduled Start Date' and 'Scheduled End Date' only.
Error: A traceback appears:"ValueError: Expected singleton:
resource.calendar()"
On '_calculate_duration_expected' method resource_calendar_id value is
getting from 'workcenter_id'.
https://github.com/odoo/odoo/blob/36459d26f1adb92f92d52ce05329e8ad3e95dd91/addons/mrp/models/mrp_workorder.py#L399-L404
Therefore in the above use case, when triggering the onchnage method,
because of resource_calender is dependend on 'workcenter' and when
workcenter is not selected it will lead to the above traceback.
Sentry-4244804815
closesodoo/odoo#128643
X-original-commit: 102ba9a848162db0029ca639ea84a9319b80d278
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
- Create a subcontracted product with components tracked by lots
- make a PO for 35 the product and send components from multiple lots
- login as subcontractor on the portal
- record uncomplete production and change the default consumed lots
Bug:
split production ignores the done quantities on the initial move
on the Backorders components are considered to be consumed in the
default order
Fix:
Consume components on the initial move as indicated by the user
reserve the remaining components for the Backorders as usual
opw-3186773
closesodoo/odoo#127467
X-original-commit: c39256ba6df257ee79fb66eab61617f5fec166b9
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to reproduce the bug:
- Enable the "by-product" option in the mrp settings.
- Create a product A with the following Bill of Materials:
- Component: 1 unit of Product B.
- By-product: 2 units of Product C.
- Create a Manufacturing Order to produce one unit of Product A.
- Confirm the MO.
- Set the quantity of Product A to 1.
- Set the quantity of the by-product "C" to 1 instead of 2.
- Attempt to validate the MO.
Problem:
When validating the MO, we check if the sum of the cost share in the
“move_byproduct” does not exceed 100. However, we do not exclude the
cancelled move, leading to incorrect calculations.
opw-3375388
closesodoo/odoo#127178
X-original-commit: 7fb1c9ff07f5ec05fc313283a497137327d9ce3a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce (Manufacturing app):
- Configuration -> Settings -> Activate `Work Orders` and `By-products`.
- Products -> Bill of Materials
- Create 2 BoM for a single product (e.g. Product A), both with
operations and a byproduct each (e.g. BP A & BP B).
- Operations -> Manufacturing Orders.
- Create a MO for Product A and save it.
- Mo was created using the first BoM and has its operations & byproducts
set in their respective tabs.
- Update the MO from first to second BoM.
Adding another byproduct, deleting it or updating it before saving
won't persist after save (it will revert to what's defined in the BoM)
This is due to `move_finished_ids` holding the values defined in the
BoM in the call to `write()` while `move_byproduct_ids` holds the
correct (current) values. But since `move_byproduct_ids` is only a
subset of `move_finished_ids`, it's not used in the write operation.
Task-3277166
closesodoo/odoo#127143
X-original-commit: 0fb2cd02622c1670ee91df48ff22a320da1b02a0
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Steps to reproduce (Manufacturing app):
- Configuration -> Settings -> Activate `Work Orders`.
- Products -> Bill of Materials
- Create 2 BoM for a single product (e.g. Product A), both with
operations.
- Operations -> Manufacturing Orders.
- Create a MO for Product A and save it.
- MO was created using the first BoM and has its operations set in Work
Orders.
- Update the MO from first to second BoM.
- Components are switched but the new operations are added to the old
ones in Work Orders.
The only way for a workorder to be deleted automatically when updating a
manufacturing order is to change its product. There was no check whether
an operation was related to another bom or not.
As different BoM can have different operations (as well as components),
it makes sense to remove operations related to another BoM when
switching them.
Task-3277166
X-original-commit: 30044e5dc698e3b8822fa7094b34c28c83861d1d
Part-of: odoo/odoo#127143
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
on this case:
1. Reorderning rule with company 1
and related product and product template is shared mean
no company selected and related product template
contain multiple bom with different company.
so using this line
bom = (product.variant_bom_ids or product.bom_ids)[:1]
from this : `product.bom_ids` as product is inherits
by template, it's tried to read all the bom of different
company and different variant too for same template.
and that will raise multi-company issue.
so I think that should be same company as related
stock rules company.
see : https://github.com/odoo/odoo/commit/6825c440d54e38ebee13a5c184aec1a40586de0d
this was generated during upgrade database.
closesodoo/odoo#125571
X-original-commit: 4edab52bdba2bb53345506a3d83f42bfdccfcd8a
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
If the user change a location type of the 'Production' from inventory locations
and installs the 'MRP' module, the traceback will appear.
Steps to produce:
- Install Stock module.
- Inventory > Configuration > Settings > enable the Storage Locations.
- Inventory > Configuration > Locations > Remove the filter 'Internal'.
- Open the 'Production' location and change the Location Type to 'View'.
- Now install the 'Manufacturing' module.
Error: A traceback appears: 'ParseError: while parsing
/home/odoo/src/odoo/saas-16.2/addons/mrp/data/mrp_data.xml:17, somewhere inside'
At the time of installing the MRP module, it will search for the production
location using the location type as the production here - https://github.com/odoo/odoo/blob/f65a9bffe2cbc03b2efc969dc205c9ba01ee9ab5/addons/mrp/models/stock_warehouse.py#L65
If the production location is not found it will raise an userError. In this
commit, the production location is created based on the company if not found. It
will lead to the above traceback.
sentry-4215564628
closesodoo/odoo#126514
X-original-commit: e8ce51dd0b5024820eee6d5e60a3a3017a0e36f6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Parth Solanki (paso) <paso@odoo.com>
Currently we skip the lot_id assignment if move.quantity_done is set,
which causes issues when using "Mass Produce" option.
closesodoo/odoo#126191
Task: 3370869
X-original-commit: 72f316a4c0ad1d443aa84051858fa6d8885b464e
Signed-off-by: Tiffany Chang <tic@odoo.com>
If there are some dependencies between BoM's operations, a traceback
will appear when the user removes one WO.
Steps to produce:
- From Manufacturing > Configuration: Enable Work Orders.
- Open any Bills of Material.
- In 'Miscellaneous' tab tick the 'Operation Dependencies' boolean.
- Set 3 or more operations in the 'Operations' tab.
- After saving the BOM add 'Blocked By' in the operations.
- Now Create Manufacturing Order for that BOM.
- Delete the one or more workorder(s) from mrp order.
- Now click on the 'Confirm' button, and the error will be raised.
The loop is incorrect because we iterate on the BoM's operations but
the keys of the dict `workorder_per_operation` are based on the MO's
work orders. Therefore, if we remove one WO, the dict will not have
any key for the related operation, hence the traceback.
sentry-4146643254
closesodoo/odoo#125990
X-original-commit: 15366af1774a571548a9c35e7dd8acbdc16ba71f
Related: odoo/enterprise#42957
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Parth Solanki (paso) <paso@odoo.com>
In this commit, I have changed `produce_delay`, `days_to_prepare_mo` and
`sale_delay` fields into Integer because it's the number of days.
TaskID - 3150983
Part-of: odoo/odoo#116799
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>
This allows to customize the values used to created lots and
avoids repeated code in enterprise module.
closesodoo/odoo#124543
X-original-commit: 0820a69a3fec90717ea10bf4c56a5609d6b376e2
Related: odoo/enterprise#42300
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The "Update BoM" button action was moved from `mrp_plm` to `mrp` so it
can be displayed if the BoM was updated now. This action can be called
for confirmed MO now.
Each time a change is done on a BoM, all the draft and confirmed MOs
using this BoM will be notified the BoM changed, thanks to a new boolean
field, `bom_has_been_updated`.
An exception however: if the MO is confirmed and the BoM's product was
changed, the MO shouldn't have the "Update BoM" button displayed.
Otherwise, it would change the finished product of a confirmed MO.
Also, it's important to notice than due to a limitation, only changes
done at the BoM level will mark it as modified. That means that
modifying subrecords in their own views (for example, adding steps in a
BoM's operation) will not mark the BoM as updated !
See odoo/enterprise#35969
task-3089368
Part-of: odoo/odoo#110227
In a Manufacturing Order, if the user manufactures a product without any
BoM, they can generate a new BoM who will take the information from the
MO. So, the new BoM will have a BoM line for each MO's component, an
operation for each MO's work order, and the By-Product lines will be
copied too.
task-3089368
Part-of: odoo/odoo#110227
This issue occurs when the user tries to create a manufacturing order while the
location type of products is not in production.
steps to produce:
1. install mrp module
2. create a new company and switch to it
3. open inventory module > settings > enable storage locations >
save the changes > configuration > locations > virtual locations
4. now change the default location type from production to any other value
5. Try to create a manufacturing order and the error will be generated.
in mrp_production the location_by_company takes default 'usage' as production:
https://github.com/odoo/odoo/blob/012cfbf82717248631626cab73867fe0362cd59c/addons/mrp/models/mrp_production.py#L474-L477
Therefore, in above use case at time if triggering onchange/compute method, if
location type is not in production, location_by_company gets `Nonetype` which
will lead to above traceback.
sentry-4215242929
closesodoo/odoo#124261
X-original-commit: b07183fbfb938b67edb220f3b53f58053bde5aad
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
ValueError: Expected singleton: stock.move(32, 33)
This error occurs when we get the multiple lines of the same products in
'finish_moves' and after that when we try to mark as done at that time this
error occurs.
applying these changes will resolve this issue.
sentry-4217897073
closesodoo/odoo#124251
X-original-commit: 4933609bd6a8473272f6bb94a1de8aea5cdf6687
Signed-off-by: Tiffany Chang <tic@odoo.com>
If End Date is already defined and user remove that date in
the form view of productivity losses, an error is generated.
Steps to reproduce error:
- Install the mrp module.
- Manufacturing > Configuration > enable work order option.
- In Configuration > Work Centers, open any of the work centers
- In form view of work center click on 'Hours Lost' stat button.
- Now in form view of productivity losses remove the date in the
End Date field and save it.
- Traceback will be generated.
Applying these changes will resolve this issue.
sentry :- 4177445007
closesodoo/odoo#123801
X-original-commit: 4f3e4fe4ba31d9d25b70f3307fcadf0e3a556af2
Signed-off-by: Tiffany Chang <tic@odoo.com>
Since https://github.com/odoo/odoo/commit/926c4d4769db1846d94e2ab5a3e9b02308b0b160
planning by workcenter no longer takes into account unavailabilities of
less than 1 day in month mode, leading to erroneous accumulations
because some calendar unavailabilities (for example from day 5:00 p.m.
to day+1 8:00 a.m.) are missing.
We return to the previous behavior by transmitting all the unavailabilities.
The planning by production no longer displays the unavailability of workcenters.
closesodoo/odoo#123898
Task: 3305266
X-original-commit: d7a803cfbed7aa28d0835f9db974802d4b6f77d1
Related: odoo/enterprise#42017
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Jean-Francois Aubert (ajf) <ajf@odoo.com>
While creating a new Manufacturing Orders, if user set value of 'date_finished'
field in the 'Work Orders' as null. As 'date_finished' field is not required,
user might have removed it by using other way.
Traceback will be generated.
'>' not supported between instances of 'bool' and 'datetime.datetime'
This commit will check the condition if the value of 'date_finished' is set or
not.
sentry - 4197616234
closesodoo/odoo#123802
X-original-commit: 11f6f2315159d321180e0fd6c9bc5747c5a7e781
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Preksha Chouhan (prec) <prec@odoo.com>
Since employees can be assigned directly to a workorder, their hourly
cost must be added to the operations cost in the Overview.
Those changes allow further override in odoo/enterprise#40953closesodoo/odoo#123551
X-original-commit: 8802907637b5d862aaa98a1828d29bc7890c53e3
Related: odoo/enterprise#41893
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit enables precompute of product_qty in MO so that the
product_qty is correctly set when a bom exists for the created MO.
it also corrects the values of `picking_type_use` fields to be used
in the barcode app for MOs.
Enterprise PR: odoo/enterprise#38096
Taskid: 3052744
Part-of: odoo/odoo#114708
This commit adds `workcenter_id` as the workcenter search field used to
have the same name as the `name` search field in the `mrp.production`
search view.
Part-of: odoo/odoo#114708
If applied, this commit will solve the issue of keyError when we confirm the
manufacturing order and work order (s) are deleted.
Steps to produce:
- Configure BOM with 'Operations'.
- Set operations in the 'Consumed in Operation' field which is in 'Components'.
- Create MO using that BOM.
- Delete the work order(s) from MO.
- Click on the 'Confirm' button.
Fix this issue when the work order is not available for that operation,
setting False in stock.move record(s).
sentry - 4171798106
closesodoo/odoo#123033
X-original-commit: 36e02b91e88c5e014d132643b6ffb24a71342d6c
Signed-off-by: Parth Solanki (paso) <paso@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
On this situation:
* P1 consumable product, kit, with components P2 and P3 in its BoM using
1 of each
* P2 comsumable product, kit, with component P3 using 1 in the BoM
* P3 storable product, 10 units in stock
Before:
The qyt_available for P1 is 10. That's incorrect: to assemble one P1 we
need precisely two of P3s, one for P2 BoM then an extra for P1 BoM.
After:
The qyt_available for P1 is 5.
closesodoo/odoo#122939
X-original-commit: b32554322d4c26665bdcb29fd58bb95f12faa20e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>
When working on an operation in workcenter that requires login, we can add multiple timers.
However, if multiple timers do not have an `end_date` and have different `loss_id`, we will get a traceback (expected singleton) when computing the interval duration.
After this fix, `_convert_to_duration` can be called with multiple productivity loss.
OPW-3292374
closesodoo/odoo#122740
X-original-commit: d9fa0d1554ad51128b33ceae5b43f4c521ff6e11
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Nogueira Cabaço Pedro Filipe (pno) <pno@odoo.com>
yhu-odoo