Choosing a negative quant to create a new move line in the detailled
operation should not take the negative quantity.
This commit set 0 instead.
closesodoo/odoo#137407
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
When the user tries to find the 'qty_available' of a product but gives
a string value instead of a float value in domain then the user will face error.
Steps to produce:
- Install `stocks`.
- Create a record rule for model `product.template`. In the domain of record
rule keep [('qty_available', '<', '10')] as a domain,
you can give any integral value in the domain but that value should be
enterred as strings (with quotes).
- Inventory > Products > Products
Error: `TypeError: '<' not supported between instances of 'str' and 'float' `
After applying our commit, if the domain is Invalid then the user will face
`UserError`. There is a function named `_search_product_quantity` which
initially checks if the domain is valid or not :
https://github.com/odoo/odoo/blob/5f1ad0c1e4c1e8ed41337ccd4c12e70c9c760c85/addons/stock/models/product.py#L342-L350
It will filter out all the invalid domain and clear search methods.
So now whenever `_search_qty_available` is called first the validity of domain
and operands of the expression will be checked.
sentry-4399815131
closesodoo/odoo#137367
X-original-commit: 92c232cca15517bd9a33a5100e7cdc42c3c25397
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Steps:
- In ``stock.production.lot`` list view, use the filter 'Expiration Alerts'
Issue:
Every lots with ``product_expiration_alert`` set to True are returned but also the ones
with ``product_qty`` set to 0.0.
Reason:
The ``StockProductionLot.product_expiration_alert`` represents lots with expiration before or equal to the current date
but don't consider the quantity of product on hand.
Solution:
After discussing with Thomas (THD), and Tiffany (TIC) the solution is to add a new custom search function on the compute
field ``product_qty`` that will be used with the 'Expiration Alerts' filter to solve the problem.
opw-3474622
closesodoo/odoo#137251
X-original-commit: 09f1a45ccbb8b463e7d9326a25c2b0b18173b133
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Eteil Junior Djoumatchoua (etdj) <etdj@odoo.com>
The error is caused by this commit: https://github.com/odoo/odoo/commit/e21c17fae8a29c8ee04883b27d761b8ce13cf5b7
Steps to reproduce the bug:
- Enable Storage location in inventory setting
- Create a storable product “P1”:
- Tracked: SN
- Create a purchase order with 1 unit of P1
- Receive product:
- location: WH/stock/shelf 1
- SN: S1
- Valide the delivery
- Go to the product form
- update the quantity:
- new quant:
- Location: WH/stock/shelf 2
- SN: use the same as shelf 1 (S1)
- You will receive a warning informing you that S1 is already used in
another location (this is expected), but the quant is still created
with this SN.
- Now try to clear the quant or refresh the page.
Problem:
You will always get a user error: "Quant's editing is restricted, you
can't do this operation." This occurs because the field "sn_duplicated"
is computed, and the write function is called to set it as True.
However, since this field is not included in the allowed fields,
the user error will always be triggered.
opw-3511463
closesodoo/odoo#137206
X-original-commit: 3a7b781dc1fad41ca0120c48f7587edb6d7adafe
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Co-authored-by: William Henrotin (whe) <whe@odoo.com>
Several reports don't include product packing info on them. This is
useful for customers to see that what they bought matches what they
expected and for pickers who need to know which product packaging they
should be selecting from stock. Reports this was added to are:
- Sales orders,
- purchase orders (including RFQs),
- picking operations,
- delivery slips.
Note that we purposely exclude backordered moves since they weren't
deemed to be necessary at the time this feature was created.
Also includes light refactoring to remove repeated code for conversion
of product qty to packaging qty and to make it easier to do this
conversion in the future (i.e. can pass product.packaging without
original record that it was assigned to)
Task id 2927379
closesodoo/odoo#96858
Signed-off-by: Steve Van Essche <svs@odoo.com>
Since https://github.com/odoo/odoo/pull/110737, it is better to use
`_read_group` instead of `read_group` in the backend. In fact, the
public method is less efficient (it computes display_name of relational
groupby, extra order, ...) and more verbose.
This commit replaces these new uses of `read_group` with `_read_group`.
closesodoo/odoo#136381
Related: odoo/enterprise#47826
Signed-off-by: Raphael Collet <rco@odoo.com>
This commit fix 3 issues with the reservation with use_expiration_date set on the product:
1) -- Discrepancy of available_quantity --
StockMove._update_reserved_quantity() works along StockMove._get_available_quantity()
If the with_expiration context is added to one and not the other, the available_quantity sent to the 'update' method will not be correct.
2) -- Can't reserve on imperishable quants --
On the Quant, if expiration_date is False, the reservation will not be possible.
Changed the domain from `expiration_date >= date` to `expiration is False or expiration_date >= date`
---
# How to Reproduce
- Create a product P, tracked by lot, with use_expiration_date = True
- Set quantity on hand to 10 (without lot)
- Create a Sale Order for 1 unit of P: Confirm
- On the Delivery, 'Check Availability' (if not done automatically)
=> The Transfer is marked as Ready (aka: at least 1 unit reserved), but nothing is reserved.
=> If you Unreserve, the product availability is shown as Available, and if your Reserve again, it is shown as 'Not Available'
OPW-3434996
closesodoo/odoo#137097
X-original-commit: b5463465fa877b9913eb9747869aae00c6b394ca
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David Fesquet (dafr) <dafr@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>
Add a new button Relocate on the stock.quant views.
This button appears when selecting 1+ quants and allows to create a stock.move to another location.
This button also allows to change the package of the quant(s) selected.
LIMITS:
- if a quant has reserved quantities, it will unreserved along with the related smls
- if a package is not fully moved to a new location, the quants selected will be unpacked
- no intercompany moves are allowed
- only available for stock manager roles
Addendum: there are 2 functions with almost identical names:
- action_set_inventory_quantity_to_zero
- action_set_inventory_quantity_zero
renaming action_set_inventory_quantity_to_zero to action_clear_inventory_quantity to make them easier to differentiate
task 3346212
closesodoo/odoo#124501
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Also, "Short Name" for duplicated warehouses was set to "COPY", because
of the 5 char limit which doesn't allow appending " (copy)" to the
original value.
closesodoo/odoo#122511
Task: 3290154
Related: odoo/upgrade#5138
Related: odoo/enterprise#42541
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Rationale: if our users want to do a pick-pack-ship manually, they were
unable to duplicate pickings by just changing the operation type.
Task: 3290154
Related task: 3010731
Part-of: odoo/odoo#122511
Steps to reproduce the bug:
- Create a storable “P1”:
- tracking= serial
- save
- Change the type of product to service
Problem:
some fields for tracked products are not hidden, because the product
tracking is not updated.
Solution:
Convert _onchange_type into compute methods.
The tracking is updated even if the change type is applied from the
"product.product" form.
opw-3499976
closesodoo/odoo#136738
X-original-commit: 22fe0ee4764705e55e81f62e07d29fc9bd8296e1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Opening the stock move form view in a picking will display the
technical name of `move_ids_without_package`. This commit change it to
be more accurate.
closesodoo/odoo#136067
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
`removeprefix` string function has been introduce in Python 3.9 but we
still support Python 3.7
This commit replaces it by an hand crafted one
Part-of: odoo/odoo#136067
Commit 4da8c6ebca change the way the
detailled operation of a stock move is openned. This has been done only
for the picking. This commit adapts the
MrpProductionComponentsX2ManyField widget to act also as the stock move
widget used in the stock pickings.
Part-of: odoo/odoo#136067
In this viewtiverse, the heroes remove the context dependencies for
`get_views`, from the views and python fields (such as domain). To reduce
inconsistencies and the number of rpc.
Current issues:
* There may be inconsistencies in views at the JavaScript level. Some
overrides modify the behavior of get_views or domains on fields via
context keys, therefore by changing the action, the rendering may be
different. However, these views are cached. However, the cache key
(Javascript) does not reflect the entire context, and requires additional
post-processing from the server.
* Multiple rpc for the same rendering. get_views being dependent on the
context, as soon as it changes, a new rpc is performed. In most cases,
when JavaScript needs the same view, there is no change depending on the
context, the rpc is useless.
* Inconsistency when rendering subviews, some views could be different
depending on the context, this context can be modified in the view itself
via the context attributes. However, the JavaScript client does not redo
an rpc for each change of these sub-contexts. Therefore the result may be
inconsistent.
Solution:
Limit as much as possible the number of context keys provided when calling
get_views, and use the context provided as a cache key. The authorized
keys are 'lang' and '*_view_ref'. For the cache key, options are added in
the get_views method.
Instead of using the context, it is inserted into python expressions.
This will be evaluated by JavaScript and thus avoids inconsistencies.
task-3414108
task-3414068
closesodoo/odoo#135145
Related: odoo/enterprise#47584
Signed-off-by: Raphael Collet <rco@odoo.com>
Choosing a quant to populate a new stock move line set the quantity done
and the reserve quantity to ensure it stay available to this particular
stock move and not empty by another picking
closesodoo/odoo#124409
Task: 3256447
Related: odoo/upgrade#5139
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Only immediate transfers should have the ability to reset the state to
draft. Also rewording it as "Plan" as the goal of this button is to left
the stock move to be done later and impact the forecast
Task: 3256447
Part-of: odoo/odoo#124409
In order to reduce the amount of RPCs in the detailed operation view.
The two wizards to populate the stock move line one2many with lot/serial
number to create are replaced with twos Owl dialogs.
only one RPCs is done to generate the stock move lines values from
either a serial number + a count or a list of lots name
Task : 3256447
Part-of: odoo/odoo#124409
The move without package as computed field bring some issue with the "no
save detailed operation" feature. Creating a stock move and directly add
some move lines without saving do not call
`set_move_ids_without_package`
Task: 3256447
Part-of: odoo/odoo#124409
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
Commit 167c51b1f9 makes `use_create_lots`
and 'use_exisitng_lots` computed fields in MRP module but did not mark
them as `readonly=False`. Thus, they were readonly by default for any
picking types.
Also, make sure new reception picking type have their `use_create_lots`
set to True and delivery picking type their `use_existing_lots` set to
True.
closesodoo/odoo#135900
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
On the backorders, the consumed quantities are incorrect.
To reproduce the issue:
1. Create two products:
- C01: consumable
- P01: storable
2. Create a BoM
- Product: P01
- Type: Subcontracting
- Subcontractor: S
- Components: 1 x C01
3. Create and confirm a planned receipt:
- From: S
- 10 x P01
4. Set the done quantity (directly on the tree view) to 1
5. Validate + Backorder
6. On this first backorder, set the qty to 2
7. Validate + Backorder
8. Validate the second backorder
9. Inventory > Reporting > Moves History, filter on C01
Error: There are three SMs, and here are the done quantities: 1, 9
and 7. The second one is incorrect, it should be 2 (see step 6).
Since [1] the done quantity is always editable on the picking's
operations, but the feature is not implemented in subcontracting,
therefore the communication between the MO and the picking does not
work well. For instance, step 4: save the done quantity and open the
MO: nothing changed on it, its producing qty is still zero. Another
example: step 4, instead of setting the done quantity directly on
the picking, open the wizard (the MO), record 3 produced products and
close the wizard. The done quantity of the stock move is 3 but the
user can still edit it. However, if he tries to update the line,
nothing will change on MO side.
On top of these "little" bugs, it may lead to a more important one
as shown in the above use case. Step 5: at some point, we split the
MO to generate a backorder for 9 x P01:
https://github.com/odoo/odoo/blob/c47e4ac7cb5fdd690f40ab2e0f8d022ba565145e/addons/mrp_subcontracting/models/stock_picking.py#L72-L76
And, as shown, the flag `set_consumed_qty` is set to `True`. As
explained in the method description:
https://github.com/odoo/odoo/blob/a2574b45aef1ff6ff3a221b996d0bb0dda2a8c74/addons/mrp/models/mrp_production.py#L1602-L1603
So, because of this flag, the method will create a SML for C01 on
the backorder, with its done quantity set to the reserved one: 9.
However, back to the first block code: `move.move_line_ids` only
contains the SML created at step 4 (i.e., the SML of the inital
SM, with a done quantity equal to 1). As a result, in the for loop,
we only define the producing quantity of the initial MO.
This is a first issue: step 6, suppose the user rather opens the
detailed operations of the line: it displays the new MO, the
producing qty is 0 but the consumed quantity of the component is 9.
This is not perfect, but let's ignore this and continue with the
above steps. The user sets the done quantity to 2 and validates with
backorder. It runs the productions split again, we use the done
quantity as producing one on the MO, but we don't edit the consumed
quantities, hence the error.
For all these reasons, the safer solution is probably to prevent the
feature 'qty done always editable' in case of subcontracting.
[1] cacc677a08066bc23e1c89df36027599d05f2a08
OPW-3441197
closesodoo/odoo#135862
X-original-commit: 049f63fbc1ab09cf75824e5c22508ea091e5c4dd
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Legacy code still use 'onchange' on the 'stock.picking.type' field code
to compute the different xxx_location_id.
As it is no more viable, this commit replace all these onchange by
compute methods.
These changes also has a side effect as some already existing compute
methods now get a set of 'stock.picking.type' in input, such that these
methods are also updated to handle this case.
closesodoo/odoo#134650
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The properties button has been moved to the contextual action menu.
The kanban view now shows partner locations and internal location directly under a view location
task 3444583
closesodoo/odoo#130509
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
When getting the available quantity of a product, it is possible to
specify the warehouse and/or the location in the context. However,
it does not correctly work. For instance, if we provide the stock
location ID (8) and the warehouse ID (1): we first use the view
location of the warehouse, and we then get the intersection between
this view location and the provided locations: nothing. In such case,
we should keep the stock location. Few other examples are given in
the test.
OPW-3450169
closesodoo/odoo#134910
X-original-commit: 8b53464dc51fb14cb37801a1d978185729c8e339
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Co-authored-by: Simon Schmid <simon.schmid@braintec.com>
To reproduce the issue:
1. In Settings, enable:
- Storage Locations
- Package
2. Create a product P
- Type: Storable
- Tracked by SN
3. Process a receipt with 1 x P, serial S
4. Return P in a package
5. Process a new receipt with 1 x P, still S as SN
Error: An error is displayed "The serial number has already been
assigned [...]". This is incorrect, the user should be able to
receive that SN.
After step 3, there exists a quant Q1: -1 x P at Supplier Location
with S. Then, after step 4, a new quant Q2 is created: 1 x P at
Supplier Location with S and the package. Because the field
`package_id` is not the same on Q1 and Q2, both quants are not merged.
As a result, step 5, we will update Q1 and have -2 x P at Supplier
Location with S. This will trigger the constraint, hence the error
message.
OPW-3390615
closesodoo/odoo#134902
X-original-commit: 0459e42ac452996831b0443bce088b84735975f0
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
There is code to block the UOM changing if there are done moves.
Because it searches in non-sudo mode, it does NOT currently
stop you changing the UOM if the product has moves in a different
company.
closesodoo/odoo#134900
X-original-commit: 426744646c25e8c2b17e3a50de186bd91b5e645f
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Minor cleanup after odoo/odoo#104741 thanks to edge-cases and the fun
complexity of logistics code. Fixes include:
- removing some readonly=False that were added on computed/stored fields
that already have an inverse func or were already not readonly (i.e.
redundant => cleanup)
- fixed visibility of qty to prod in subcontractor portal view of a MO
(i.e. yay they know how much they're supposed to make again)
- remove unused imports
- adding back in readonly functionality of default dest of repair
operation type (and removing the now useless field override that used
to add in the readonly functionality)
- adding back in the `_set_product_qty` inverse function since it was
probably removed by mistake (and is still important to have)
unrelated to viewpocolypse change, also fixed:
- mobile view of PO was for some reason allowing products to be changed
in already confirmed/done POs, which could lead to some inconsistent
data => made this consistent with existing desktop view behavior
closesodoo/odoo#133502
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps:
- Create a product tracked by serial number
- Create a new scrap order in inventory -> operations
- Add the created product, the serial number and save.
Issue:
The quantity is automatically set to 0.00 after saving.
Reason:
The ``StockScrap.scrap_qty`` field is computed and has a default value set to 0.0. On the
xml form view when ``StockScrap.tracking`` is set to 'serial' the field is readonly and is not
sent to the server when saving so the default value is used.
The problem appears because initially the ``StockScrap.scrap_qty`` was precomputed so even it wasn't
sent by the form, we already had the value. With the changes made we can't use ``precompute=True``
because ``StockScrap.scrap_qty`` depends on fields which aren't precomputed.
Solution:
In this context we have 3 cases:
- If ``StockScrap.tracking`` is 'none', ``scrap_qty`` is not readonly so sent.
- If ``StockScrap.tracking`` is 'lot', ``scrap_qty`` is not readonly so sent.
- If ``StockScrap.tracking`` is 'serial', ``scrap_qty`` is readonly so not sent.
As the only case of the issue is when the product is tracked by serial number(only one product) we can,
set the default value of ``StockScrap.scrap_qty`` to 1.
opw-3470888
closesodoo/odoo#132895
X-original-commit: 0d9fa534c3c17e87210f9d24cc90991d6dd8c0be
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Eteil Junior Djoumatchoua (etdj) <etdj@odoo.com>
Company can have multiple warehouses,
when user open replenishment and company has multiple warehouses.
this will lead to below traceback.
Steps to reproduce the error:
- Go to 'Manufacturing' > Configuration > Settings > Enable Subcontracting
- Go to 'Contacts' > Create a Contact > Sales & Purchase >
Open Subcontractor Location > Enable Replenish Location
- Go to 'Inventory' > Configuration > Warehouses > Create multiple warehouses
- Create a storable product > Create BoM > Set Subcontracting in BoM Type >
Set already created contact in Subcontractors > Save
- Go to 'Purchase' > Set Subcontractor in Vendor > Add Product > Confirm Order
- Go to 'Inventory' > Operations > Replenishment
Error: A traceback appears:
'ValueError: Expected singleton: stock.warehouse(1, 2, 3, 4)'
https://github.com/odoo/odoo/blob/3864542914efcb9d4e3cabd3cfdeecb842e4f380/addons/stock/models/stock_orderpoint.py#L414
here, we can get multiple warehouses for a company.
So it will lead to above traceback.
sentry-4358838167
closesodoo/odoo#133178
X-original-commit: fd0e104c13fae2c2b34443502b88017ef98e5523
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
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>
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
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>
The error can be raised either when a move is in state done or cancel. However, the error message only says we cannot split split if the move is in done, which can be misleading.
closesodoo/odoo#132433
X-original-commit: 45bab967033531e0391a923ef1a2186955c36eeb
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Pedro Nogueira (pno) <pno@odoo.com>
In https://github.com/odoo/odoo/pull/110737, I didn't consider that
compute could be called on NewId record with `_origin`. Some compute
methods are badly refactored with the new signature of `_read_group`.
We use recordsets returning from `_read_group` to assign field value to
`self`. But if `self` contains `NewId` with `origin`, these records
don't represent `self`, it contains real record instead of the one with
NewId + origin. Then the assignations are done on records not in `self`
which may lead to generate traceback or write to other records during
an onchange.
Fix multiple compute to work correctly with NewId (origin set) record.
X-original-commit: bd22d0a5c479a72cdaf799309387e41ce692bb29
Part-of: odoo/odoo#132261
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
Steps to reproduce:
- Deliver an SN-tracked product with the Destination Package set (put in pack button also sets this).
- Return that product without setting the Source Package (you can also click "put in pack" which will put the product in yet another pack).
- This already results in two lines with the same SN in the same location, one with +1.00 and one with -1.00 quantity.
- Deliver that product again and put in pack.
- Now there's three lines with the same SN in the same location, two with +1.00 and one with -1.00 quantity.
Bug:
source Package isn't set bydefault when confirming the move_line
we update the stock quantity for that lot_id and Package set to False
the existing quantity has a Package set so it is filtered out and a new
negative quantity is created
Fix:
set the source Package on the return
opw-3179388
closesodoo/odoo#132056
X-original-commit: 9d2d3911a3ac6711d3040d22e146f9eb18de2197
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit's purpose is to allow the overwrite of a condition inside
the action_launch_stock_rule in order to ensure the data to be corretly
updated in the flow of the industry_fsm_stock
task:2720328
closesodoo/odoo#114757
Related: odoo/upgrade#3607
Related: odoo/enterprise#23000
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce the bug:
- Assume the current date is August 1, 2023.
- Go to general settings:
- set purchase security lead time: 20 days
- set manufacturing security lead time: 25 days
- Create a storable product “P1”
- Routes: Manufacture + buy
- Manufacture lead time: 1 day
- Create an order point:
- preferred route: Manufacture
- Quantity to order: 5
- Click on “Order once”
Problem:
A manufacturing order is created, but the "Scheduled Date" is incorrect.
Instead of being set to August 1, 2023, it shows August 7th.
The issue occurs because initially, we calculate the `Lead days date`
as follows:
Today's date (August 1st) + manufacturing security lead time (25)
+ Manufacturing Lead Time (1) = August 27th.
However, we use the purchase security lead time (20) instead of the
manufacturing so 27 - 20 = August 7th
To determine the exact date, we call the function
`_get_date_with_security_lead_days`. In which we try to get the
appropriate rule to use. However, in this case, the preferred route
of the orderpoint is not passed as a parameter to the function.
Therefore, we use the first rule of the first route ("buy"), and we end
up using its security lead time.
opw-3439546
closesodoo/odoo#130932
X-original-commit: 5726c8882ae92eca3adfe19500c109ef8bae38a2
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
With this commit you wil have the function _get_gather_domain so you can
override and manage the gather_domain by your own logic
closesodoo/odoo#131476
X-original-commit: 92b6fd647c77ae88dfb685654ba9e9f14b7a1d03
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
On a putaway rule, the "Having Category" condition is not always
respected.
To reproduce the issue:
1. In Settings, enable:
- Storage Locations
- Storage Categories
2. Create a Storage Category SC:
3. Create two locations L1, L2:
- Parent: WH/Stock
- Type: Internal
- L2 only:
- Storage Category: SC
4. Create a putaway rule:
- When in: WH/Stock
- Store to: WH/Stock
- Having Category: SC
5. Create one storable product
6. Update its on hand quantity:
- 1 product at L1
7. Create a planned receipt R for one product
8. Mark the receipt as Todo
9. Click on 'Set Quantities'
10. Open the detailed operations
Error: The destination location is L1. The putaway rule has been
applied without the storage category constraint: the destination
location should be L2
When applying the putaway rules, we first check if one of the
relevant locations already contains that product. And, if it's the
case, we use that location as destination location. However, we
don't filter out the locations without the correct storage category.
This explains why L1 is found and used.
OPW-3437174
closesodoo/odoo#131361
X-original-commit: 66c11acdbedf8d1bcae6deb8ec54c5da5a3ae16d
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Before this commit, there was no functionality to trigger replenishment before
min qty is reached. This commit adds a "Order to max" button to top of list view
of replenishment when orderpoint(s) are selected. This button will trigger
replenishment for lines where Max Quantity - forecast > 0.
Taskid: 2964309
Part-of: odoo/odoo#101090
This commit improves the performance of reservation by removing
the `get_available_quantity` and `update_reserved_quantity` inside
`_action_assign` which each does a search on quants with the same domain,
both of which are done per move to assign.
Instead the quants needed by the moves to reserve are fetched first and
are then filtered in memory for each move to reserve from.
A new function is provided `get_quants_by_product` which should be used
when reserving moves to fetch the relevant quants once and then call
`_update_reserved_quantity` on them which will filter them in memory.
This avoids searching for quants for every move.
The changes in `point_of_sale` and `product_expiry` are all
due to the the method signature change and change nothing in the flow.
Performance stats:
These stats are from the Odoo profiler on the `_action_assign` called
on a specific number of moves. For each number of moves the duration was
taken multiple times and the average was taken. The 10 moves durations
were quite random since the numbers were very small and could be considered
an outlier.
Before this commit:
| No. of Moves | SQL Queries | Duration (s) |
| ------------- | ------------- | ------------|
| 10 | 70 | 0.044440283 |
| 100 | 633 | 0.398992664 |
| 1,000 | 4,518 | 6.264924025 |
| 10,000 | 46,954 | 79.76809310 |
After this commit:
| No. of Moves | SQL Queries | Duration (s) |
| ------------- | ------------- | ------------|
| 10 | 62 | 0.062840558 |
| 100 | 540 | 0.323033646 |
| 1,000 | 3,893 | 4.062329989 |
| 10,000 | 39,259 | 49.92596793 |
Besides 10 moves duration, there's a general performance
improvement of 20% - 35%
closesodoo/odoo#116803
Related: odoo/enterprise#40633
Signed-off-by: Tiffany Chang <tic@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>
William Henrotin