The field is now `quantity`. This wasn't spotted before because the
method is not used anywhere.
opw-2008491
closesodoo/odoo#34067
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Have a multi-company setup, with shared products.
Write the default code of a product; an access error is raised on inventory.line
On inventory.line, the field product_code is defined as related to
'product_id.default_code', and stored.
So when writing on the default_code of a product, we get the inventory lines of
other companies. For obvious reasons their access is protected by the record
rule "Inventory Line multi-company", therefore the access error is raised.
To avoid that situation stored related fields should be in compute_sudo.
Note that similarly this is necessary for product_name.
There is one more subtlety: directly writing on the product.product does trigger
the access error, but writing it on the product.template does not.
opw 2007167
closesodoo/odoo#34019
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
cancelling propagation in a move chain was True be default. That means,
without any configuration, a cancel move will always cancel its next ones
This commit change the default to allow only cancelation of move chain
until the stock location. Here are 2 examples :
1. Reception and delivery in 3 steps. The moves chain is the following:
Vendor -> Input -> Quality -> Stock -> Pack -> Output -> Customer
In case the Purchase order is cancelled, we want to move from Vendor to
Stock are cancelled but not the ones from Stock.
2. pbm + sam. The manufacturing process is the following;
Stock -> Pre-prod -> Production -> Post-prod -> Stock
cancelling the first move should cancelled until Production and not after
Task : 1913297
when we select places warehouses where route can be applied, then unselect that warehouses, warehouses values on m2m tag are not deleted.
because of wrong value empty list on onchange. so remove all records of warehouses if warehouse option was not selected.
closesodoo/odoo#33883
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Create two pickings, add them to a batch.
Set a quantity less than the order to done on each.
Confirm and set to done. A wizard asks if a backorder should be created.
If confirmed, the first picking is done with a backorder but not the second.
Since the method is in api.multi, we can simply get all pickings.
opw 2004727
closesodoo/odoo#33902
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Since the company is not stored anymore on the user and is in the
environement, some parts of the code that was based on the current user
company cannot work anymore.
We've adapted the code to take the company from the relevent documents
to avoid having inconsistencies through the different documents
generated in the point of sale.
TASK-ID: 1997613
closesodoo/odoo#33556
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Before this commit, we had two form views for production lot: one more
complete and one simplier.
The complete one was displayed when we come from the prod lot list view,
and the simplier one in any other case.
But actually, we need to display the simplier one only with "Create and
Edit" and display the complete one in any other case, but it's
impossible to do with only two distinguish views.
So, we keep only one view with all elements and we display or hide some
fields or button in function of the context or if the record is new.
Task #1935921
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
Made some changes in stock.quant model to allow user to modify product
quantity easier.
To allow the edition of quant without opening more permissions on the
model, we switch to sudo in create mode and write if the conditions are
met (special key in context + access rights on the current user + write
on a specific field).
Also, we have two list views for the quant:
- The old list view who still readonly.
- A new list view where user can create new quant or edit quantity
of existing ones
We display the second one if user is a stock manager.
For existing quants, user can modify counted quantity (which will modify
product quantity). User can also create new quant, in this case:
- The quant is really a new one (ex.: new product/location
association) so will simply create a new quant.
- A corresponding quant already exist, so will modify the existing
quant instead of create a new one.
When an user creates a new quant, the model will check each time a
non-quantity field (product, location, SN/LN, package or owner) is
modified to see if corresponding quant exists. In this case, it'll get
the quant ID and will update reserved and on hand quantities.
If user didn't change the inventory quantity, it'll be updated too.
On product form view, the 'Update quantity' button was removed as user
can now simply modify quant with 'On Hand' stat button.
Task #1935921
Co-authored-by: sle-odoo <sle@odoo.com>
This commit moves the "propagation minimum delta" from a company setting to a
per-rule setting.
We implement this idea in the stock module and take this opportunity to clean
up the override of stock move's write.
We add a few basics tests.
task-1913401
The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
- Activate 'Lots & Serial Numbers'
- Create a stockable product A, enable tracking 'By Lots'
- From the menu Inventory > Operations > Transfers, create a picking:
Set a picking type
One line of A
It is not possible to set the lot number to validate the transfer.
When creating a picking from the menu, the context key
`default_picking_type_id` is not set. Therefore, the field
`picking_type_id` is empty on the `stock.move`.
We can fall back on the `picking_type_id` of the picking.
opw-1981958
closesodoo/odoo#33611
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The field had no triggers on the compute method.
As the field is not stored, it works fine in most cases where the value is
computed in a different transaction that the modification but when it is the
case (e.g. OCA/connector-prestashop#101), the values were incorrect
Add the correct triggers to recompute the value when needed
closesodoo/odoo#30024
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Usecase to reproduce:
- Install stock, mrp, purchase
- Go on warehouse form view
- Click on Routes button
Either one of the route manufacture or buy is missing.
All implementations/overrides of stock.warehouse._get_all_routes()
call their parent's implementation of get_all_routes_for_wh().
which is a reference to stock.warehouse._get_all_routes() but that means
that the route 'mixin' behavior can be skipped.
(the reference is to the base implementation of _get_all_routes())
Fixes#33286Fixes#33288
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Putting *args and **kwargs confuses the function `odoo.api.split_context`.
This causes that a call to `search` via XMLRPC gets the wrong argument: takes
the first argument of ``args`` as the context.
Example which ignores the `count=True`::
```
api.call_kw(self.env['product.product'], 'search', (
[], False, False, None, True, {'lang': 'en_US'}
), {})
```
would ignore the `count=True` and use the wrong argument for context.
Issue introduced in commit 15ea753a.
Since:
`def search(self, model=None, *args, **kwargs)`
is equivalent to:
`def search(self, args, offset=0, limit=None, order=None, count=False):`
because the call to the super will anyway call the parent method, we can
change the method arguments.
note: this is only for [10.0,saas-14] where 15ea753a is.
closes#33147
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Nicolas Lempereur <nle-odoo@users.noreply.github.com>
Purpose: filter product by location of warehouse failed due to the
control panel refactoring (odoo#29106). This commit fix the way the
product quantities are computed when location/warehouse into filter
context.
Task:1941639
Co-Authored-By: Martin Geubelle <mge@odoo.com>
closesodoo/odoo#31316
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Install the sales and stock applications
- Create a stored product tracked with unique S/N
- Create an initial inventory for this product with 2 SN 001 and 002 and
validate it
- Create a SO for 1 unit of the product, and deliver it using SN 001
- Display the product form view
In the form view of the product, the quantity on hand is 1 (correct).
But when we click on the smart button, we see that the Stock location
has a quant for SN 001 and a quantity of 0.
The vacuum should be run when we access the stock information from the
'On Hand' stat button.
opw-1999545
closesodoo/odoo#33687
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Configure a route to be in 3 steps
make a PO, validate all three pickings
Go on the final picking, the one that has the destination to the Stock
Click on the smart button to access the traceability report
unfold as many lines as you can
Before this commit, the first picking of the whole tree (Vendors to Input)
appeared as a direct child of the final picking,
as well as a child of the intermediary picking (as it should)
- Quality > Stock
|
- Input > Quality
| |
| -Vendors > Input
- Vendors > Input
After this commit, the final picking contains only the intermediary
which in turn contains only the origin
- Quality > Stock
|
- Input > Quality
|
-Vendors > Input
OPW 1970286
closesodoo/odoo#32953
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Steps to reproduce the bug:
- Install MRP
- Uninstall MRP
- Install MRP
Bug:
An error was raised by sql constraint 'barcode_company_uniq' which ensures that
a barcode for a location is unique per company.
But when uninstalling MRP, some locations such as pbm_loc_id or sam_loc_id are set to
active = False and when re-installing MRP, the function _create_missing_locations tried
to re-create these locations and the sql constraint was raised.
opw:1967534
closesodoo/odoo#32882
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Christophe Simonis