Steps to reproduce:
- Manufacturing app > Operations > Manufacturing orders > Create
- Set product to [FURN_7800] Desk Combination > Save > Confirm
- Click on scrap, choose any product > Done
- Edit the manufacturing order > set the quantity to 1/1 > Save
An error pops up: You cannot change the UoM for a stock move that has
been set to 'Done'.
This happens because the scrapped product has its destination location
wrongly set to the production location of the manufacturing order.
Because of this, it is considered as a component of the manufacturing
order. The scrap is also confirmed right after creation, so its state
is set to 'done'. Finally, when confirming a manufacturing order, all
of its component moves are also confirmed, hence the error.
This commit prevents the override of the scrap's destination location,
so that it is not wrongly considered a component anymore.
The commit also adds tests for the override method, added in
commit 0b247ab17ccc5be0c2058ef92ccf3502c97e0bb3
opw-2945182
closesodoo/odoo#99218
X-original-commit: 81820d4df5f23d9b6b2701e513ada89b528a865a
Signed-off-by: Adrien Widart <awt@odoo.com>
In a lot of test class, we use `setUp` instead of
`setUpClass`. `setUp` is execute for each test method and `setUpClass`
will be execute only once by Class (and use savepoint + rollback).
Then change setUp into setUpClass reduce the time to make all tests
and avoid to repeat this error for the future.
closesodoo/odoo#78082
Related: odoo/enterprise#21563
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
This commit removes stock.inventory(.line) and moves its general
functionality into stock.quant. Some features are lost during this
switch as well.
Feature Additions:
- New single list view for inventory adjustments (no more multiple
inventory adjustment records to keep track of!)
- Improved cyclic counts (annual inventory day setting) + next inventory
dates are immediately viewable in view (vs auto-generated inventories
based only on location)
- Specific quants (i.e. counts) can be assigned to users for more
flexibility (vs only able to restrict by location + product
combinations)
- Counts can be requested (i.e. bulk assigned to user/for a specific
inventory date)
Feature Removals:
- Can no longer look at previous inventory adjustments linked to a
specific record. Each quant has a history button to show inventory
related moves. [relevant account moves are also now harder to see via
stock as well]
Other changes:
- Bulk of changes were for demo/test
- Some changes were done to ensure "Update Quantity"/"Inventory Report"
views still mainly function the same as before with the exception of a
new column added to support updating quant quantities in these views.
Task: 2440026
ENT PR: odoo/enterprise#17329
Upgrade PR: odoo/upgrade#2326closesodoo/odoo#68409
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Removed abstract workorder
Removed the integration of expiry wizard in tablet view since it should
be moved in enterprise in the tablet view implementation (not possible
to set consumed lot on workorders on community anymore)
Refactor _set_quantity_done to use ORM command in order to not return a
dict with vals to_create/to_write
task-2241471
Now, by default, a Bill of Material have a flexible
consumption instead of strict consumption. Also
add new consumption choice: a flexible consumption
but with a warning when the bom isn't respected.
Also, now, the strict (a new warning option) consumption
is checked only when we try to mark as done the MO.
task-2241471
Set the operations directly on the Bill of Material.
Duplicate the demo data where a routing was shared.
Adapt the tests.
Remove the following feature:
- set the same routing on parent and kit child bom
- when planning, if the component of the kit have the same operation
than a component of the parent bom, merge these operations
task-2241471
TL;DR: remember `osv` and `except_orm` ? You can forget about them.
* Deprecated `except_orm` dropped.
* `UserError` elevated as super type of all user-related
errors.
* Unused `DeferredException` dropped.
* Unused `QWebException` dropped (real one is in `qweb.py`).
* `MailDeliveryException` made a python exception.
* `name` legacy exception attribute made an alias of the python standard
`args[0]` attribute and deprecated.
* `value` legacy exception attribute dropped.
* `exception_type` RPC error response key dropped.
* Deprecated `osv` module dropped.
* `--osv-memory-age-limit` cli option made an alias of
`--transient-age-limit` and deprecated.
The `odoo.exceptions.Warning` have long been a deprecated alias to
`UserError`. It is going to be removed in a future version but first we
explicitly deprecate it with a warning.
The `odoo.exceptions.DeferredException` was a very old internal
exception, it has been removed without deprecation notice as it is never
raised.
The `odoo.exceptions.except_orm` has been a deprecated exception type
with deprecation warning for 5 years, it has been removed in favor of
UserError which becomes the super class of all user-related errors.
The `odoo.base.models.ir_mail_server.MailDeliveryException` was
inheriting `except_orm`. As it is not related to a user error but is
more of a problem an admin much take care of, the exception has been
made a Python error.
The `exception_type` JSON key in RPC error responses was holding an
hardcoded value derived from the exception type. Its usage has been
dropped in favor of the `name` JSON key that holds the precise exception
name. Again as it was hardly used in the source code (beside the crash
manager) it has been dropped without deprecation warning.
Since we are here trying to clean odoo custom exceptions, we are also
deprecating the `name` exception attribute in favor of the more standard
`args[0]` attribute.
The `name` (along with `value`) were two attributes used to raise
`except_orm` exceptions before the introduction of `UserError`,
`AccessError` and related exceptions. The `name` attribute, at the time,
was holding the exception type/title. Nowadays it contains the error
message. The `value` attribute, at the time, was holding the error
message. Nowadays it is no more used.
The `osv` module contains very old deprecated aliases. There is no
simple way to log a deprecation warning for osv, osv_memory and
osv_abstract but as they have not been in use for ages, they have been
removed too. To be consistent, the `--osv-memory-age-limit` cli option
has been made a deprecated alias to the `--transient-age-limit`.
closesodoo/odoo#45723
Task: 2187728
Related: odoo/enterprise#9162
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Ensure proper domains are applied and enforced on relation fields thanks
to the `check_company` attributes.
Make sure unbuild have proper sequence for each companies.
The produce wizard and workorders company is the one of the production.
The BoM line company_id is the one of its bom_id.
Added some tests.
task-1985992
Purpose
=======
Fields `customer` and `supplier` on `res.partner`
are mostly used in domains of many2x fields.
Those domains can confuse end users because they don't
see the partner they are looking for; and it's not obvious why.
Some identified problems:
1. It can lead to duplicated partners: the user does not find
the partner, so he creates a new one.
2. The user imports supplier contacts in the Contacts app, so they
don't get the `supplier` flag. Then the user wants to make a purchase order,
and cannot find the new suppliers in the list
3. A user removes the customer flag on a prospect, because they don't think
it's a customer yet - except now they can't make a quote for that customer...
Specification
=============
Remove the two mentioned fields.
Since fields `customer` and `supplier` have been removed, all partners
are now shown in many2one dropdowns.
But in some cases, not all partners are relevant or some are more likely
to be relevant than others. e.g. when creating a PO, top suppliers have a
higher priority than other partners.
So, adapt the places where those fields were used with the new mechanism to
display the searched the partners, according to the number purchase/sales
orders they made.
TaskID: 2031147
Co-authored-by: Yannick Tivisse <yti@odoo.com>
Change the use of Inventory Adjustment, notable changes are:
- Removed filter field: When user creates a new inventory
adjustment, he can set one or multiple locations and/or products.
An inventory adjustment will worry only about defined
locations/products, but if neither product or location was set,
it'll manage all stock.
- Inventory Adjustment Lines have their own view instead of be
listed on the Inventory Adjustment form view.
Inventory adjustment lines have new color legend:
- Red: The quantity is outdated.
- Blue: There is difference between the on hand quantity and the
counted quantity.
New inventory lines created by the user are written in bold.
- User can't modify already existing inventory lines, except for the
counted quantity.
- When an inventory line is outdated, the user has the possibility
to select and update it, that'll recompute the on hand quantity.
- When an inventory adjustment is validated, it will take in account
only the difference between the theoretical quantity ('On Hand
Quantity') and the counted quantity to adjust the quants.
- When an inventory adjustment is canceled, it will keep its
inventory lines and won't regenerate them when re-started.
- When an Inventory Adjustment generates Account Moves, user can now
find them in a stat button in the Inventory Adjustment form view.
Also, made some changes in demo data to match new requirement.
Task #1935921
Commit 5ef46664a2 share code between produce
wizard and workorder. Field final_lot_id is now commonly used but not very
well named. This commit rename it into finished_lot_id as it represent the
lot number of the finished product.
Task : 1998064
closesodoo/odoo#32761
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this commit, when a product goes from manufacturing order to
location having putaway strategy, if this product is tracked, the
putaway strategy don't apply.
opw-1948514
closesodoo/odoo#31808
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
With this commit, when a kit is processed trough an immediate transfer,
the quantity done set on the kit is now propagated to its components.
TaskID: 1896772
closesodoo/odoo#28998
The purpose is to be able to plan manufacturing order
without propagate the components's documents directly.
Except when the manufacturing comes from a pull rule, it will
be confirmed directly.
In order to do it, it will just create the moves without confirm them.
They will be only confirmed after a 'Mark as Todo' click.
Refactor production order state:
- Directly have an idea of linked workorders's state
- Computed in order to manage it in a single method
- Add tooltips for each state
Remove the None in availability selection field instead use a False
Also refactor the ready_to_produce field in order to only set as
assigned a production order that have the component for its first
workorder.
Currently MRP do not handle multi locations for components. In order to
be able to use both feature at the same time, we could:
- Improve mrp in order to handle multiple stock.move.line for a
componenet stock.move
- Add a rule that allow to bring all the good from multiple location to
a single location. (was already possible but it requires some
configuration)
This commit introduce a checkbox on the warehouse in order to
automatically configure all the routes/rules/locations/picking_types,...
necessary to bring all the components to a single location before
running the manufacturing order.
Technically it also refactor some stock_warehouse.py methods in order to
easily override the picking_type, rules and routes creation.
Thank to Hetashree Chauhan <hch@odoo.com> for his help.
task_id: 27785
The method 'action_done' on inventory adjustment became private and the
action launched from the view is now 'action_validate', so we adapt
those tests to use the new function.
TASK-30921
This implements a warning when the user tries to do any of the
following operations on a product that is not in stock:
- Scrapping
- Unbuilding
- Repairing
The warning displays the current stock of the product in question per
location which can be helpful in case the user selected the wrong
location.
Stefan-Calin Crainiciuc (stcc)