This commit replaces the opening of the stock moves detailed operation
wizard by the one2Many record preview. This means creating a move in a
picking is still done via a new line but the edition is done via the
`fa-list` button that open the record in the web client. The goal is to
reduce the RPCs call as much as possible. The stock move lines data are
stored in the stock move record until the picking save.
Additionally, this commit change a bit the immediate transfers flows.
The stock move show only initial demand (`product_uom_qty`) but the
column wording is still "Done". In the detailed operation view, the
stock move line `qty_done` is displayed as "Reserved".
At picking validation, the user is expected to enter the same quantity
in `product_uom_qty` and `quantity_done`. If `product_uom_qty` is equals
to 0, the done quantity is used as actual transfer quantity. If
`product_uom_qty` is different than 0 but small than the done quantity,
an error is raised.
Task: 3256447
Part-of: odoo/odoo#124409
Issue:
======
You can create the same sequence with the same code
Steps to reproduce the error:
=============================
- Install inventory and activate storage locations
- Go to inventory/configuration/Operations Types
- Create 2 operation typs with the following values:
name :any random name , type of Operations : internal transfer,
sequence prefix : test , locations as WH/Stock
- Go to sequences and search for test
- You will have 2 duplicate sequences with the same values
Origin of the problem :
=======================
- Creating an operation type always creates atuomatically a sequences if
the sequence_code is provided but the sequence_id isn't.
Solution:
=========
Display an error when the name already exist.
opw-3238331
closesodoo/odoo#132982
X-original-commit: e1f9480c7aa2a982d828ffd0fbc032e4066089d4
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
do not create stock move line from quant for consumable products
Task: 3256447
X-original-commit: b327825de0b50de9cdb81fc9e8384c503351d6d7
Part-of: odoo/odoo#126069
add the following features:
- add location in form , kanban and list view. Change location creates move
- add smart button for repairs
- add next activity widget in list and kanban
- from the lots/SN smartbutton on the product form, open the kanban view
- show the last delivery partner on serial
closesodoo/odoo#117316
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
In case package and consignment settings are activated, choosing a
quant to create a move line is easier if the package/owner is in the
quant name.
Task: 3256447
Part-of: odoo/odoo#122445
When creating a wizard `stock.return.picking` and call
`_onchange_picking_id`, the creation of return picking line will perform
a write on move linked with it, due to `uom_id` being set as related with
`readonly=False`. Set `readonly` to `True` to avoid it
closesodoo/odoo#77242
X-original-commit: 6bdc99f8b67da069c8d26c73b5499d0b0c019c1e
Signed-off-by: Tiffany Chang <tic@odoo.com>
Behavior prior to the fix:
- when adding a filter on "Quantity < 0" (or > 0) on the forecast
inventory report the quantity reported becomes incorrect: for example if
there is a restock on Tuesday and a shipment on Friday that drives the
forecasted quantity into a negative, the forecasted inventory report
instead reports a negative quantity on Monday.
- the problem occurs because the view the report is based on is built
using positive and negative entries that are supposed to cancel each
other when accounting for stock items (quant). This way the quantity is
reported as 0 before the quant is moved in the inventory (there is a
positive entry for the quant, and a negative entry for the move up to
the move effective date). But when a filter on quantity is placed the
"cancelling" entries are not loaded and the report ends up with just the
negative value
Behavior after the fix:
- the quantities are reported as expected: with a negative on Friday,
and 0 on the days before
- to achieve this the view was modified to perform the grouping of
forecast entries inside of the view. This way we have one row per
product / day / state and we don't risk selecting only part of the
report.
- as the view is only read in aggregate there will not be any visible
changes to its consumers
opw-2379098
closesodoo/odoo#62574
X-original-commit: c16d4b5e7b9181c2c792f595a117de10510d45be
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
Values for "context" and "data" key were injected into the action
dictionnary by report_action to be used by the /report controller
later
Courtesy of William Henrotin (whe) for the test
X-original-commit: 4d43a301fd10cfeb498d9bf6b614779e26e12d16
Ensure proper domains are applied and enforced on relation fields thanks
to the `check_company` attributes.
product.template
- make responsible a property field in order to ensure proper next activities when a product
is used between multiple companies
stock.putaway.rule
- added a company_id field
stock.move.line
- company_id is not related anymore since a move line can exist without a move until its validation
stock.package_level
- added a company_id field
stock.picking.type
- company_id is now required
stock.production.lot
- added a company_id field, adapted the constraint accordingly
stock.quant
- check the consistency only in inventory mode
stock.quant.package
- company_id is now empty if the package is empty
stock.picking
- company_id is now related to the one of its picking type
Added some tests.
Moved stock_traceability in the `report` directory.
Removed useless /tests/tours/route.js.
task-1985992
Adds a button in stock move form view to generate multiple serial number
and assigns them to stock move lines.
Through a wizard, the user enter the first SN. Then, starting with this
number, iterates to assign and increment the SN on each move line who
doesn't have already one.
Task #1832645closesodoo/odoo#33466
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
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>
before on runbot:
odoo.addons.stock.tests.test_move tested in 31.79s, 63166 queries
odoo.addons.stock.tests.test_move2 tested in 33.69s, 68046 queries
odoo.addons.stock.tests.test_quant tested in 8.48s, 15351 queries
odoo.addons.stock.tests.test_stock_flow tested in 16.99s, 31506 queries
amounting to 90 seconds on a build page
after om runbot:
odoo.addons.stock.tests.test_move tested in 12.41s, 24197 queries
odoo.addons.stock.tests.test_move2 tested in 13.55s, 24254 queries
odoo.addons.stock.tests.test_stock_flow tested in 9.74s, 15795 queries
amounting to 37 seconds on a build page
Use savepoint case instead of transaction case.
We took the opportunity to rename the master data more appropriately,
which results now in a bigger diff in TestMove and TestQuant. In
TestQuant, the master data creation had to be moved in the setUpClass
too.
We removed test_shipment as test_backorder_1-4 in tet_move_2 covers the
same parts of the code.
A new exception has been added to detect inconsistent reports. However, many are not structured as expected. Thus, the change consists mainly of checking only when the print has to be separated in part to attach it to the respective documents.
We now take the page tag instead of the article, because the article tag is in the layout, so to separate the file, the t-call had to be inside the t-foreach (for the separation) and so possibly read the assets several times. Since all templates have the first tag (in the t-foreach) tag page, the choice is more sensible.
The javascripts files used in readonly were taken out of the editing assets.
A turn was made but not activated, it works locally, but on the runbot, an error is triggered when generating assets after choosing the settings.
This commit block users to change unit of measure factor. if there are
reserved move on product using this UoM. This will allow the quantities
to be correctly unreserved when the stock move will be confirmed.
Task id : 1844684
As for consumables stock levels are not that important,
it should be ok to scrap a consumable at all times,
even if the stock becomes negative.
Tests were added to check what happens with a consumable/stockable
product if stays positive/goes negative.
Including
- unit tests for test/inventory.yml
- unit tests for test/move.yml
- unit tests for test/shipment.yml
- integration of test_reuspply.py
- integration of test_owner_available into test_product.py
New tests are temporarily deactivated. Indeed they rely on onchange methods
that will change during migration. Tests will be reactivated after migration
and updated.
If you set WH B to be resupplied from WH A, then the scheduler will
generate a procurement with warehouse_id = B and location_id = B.stock.
Running the procurement will find the resupply rule, and this will
create another procurement with warehouse_id = A and location_id =
transit location.
However, without this patch, the resupply route is not part of the
route_ids of warehouse A, and so the 2nd procurement goes in exception
because if cannot find a rule (the search will force a rule linked to a
route which is part of A.route_ids).
Closes#7956
William Henrotin