The rational is:
Currently we have 2 columns. One for reservation, the other
for quantity picked.
However in real time, either you follow the reservation and everything
goes well. Otherwise you pick something else. In the case where you
pick somewhere else than reserved, you would like to modify the
reservation to have something similar and free the quantity you
didn't pick and expect the system to not suggest the ones you took.
In other hand, we always want to have the reserve quantity similar to
the done.
On top, having two columns could be confusing for the end user.
The cons:
-The qty_done column could be use during the picking, to
remember if something has been pick or still to pick.
- For some flow (put in pack), it's easier to write a part of the quantity to pack
and still want to reserve the full amount of product.
We goes back and choose a ligther interface over complex feature.
Changes:
Qty done and reserved qty are merged into a single column.
A new checkbox on the move exists to mark it as picked or not
Since the reservation always follow the quantity, it's now possible
to have more reserved quantity than stock. However the system will
never propose it and the inventory showing reserved > quantity should
be a warning.
The system should never modify a move that has been picked. We don't
want to overide the user action.
Regression:
Not able to pick a single stock.move.line
closesodoo/odoo#137864
Related: odoo/enterprise#48709
Related: odoo/upgrade#5310
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>
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>
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>
This commit fixes a really old grammar error in the help message of the
message_needaction_counter field.
Before this commit: “Number of messages which requires an action”
After: “Number of messages requiring action”
The subject of “require” is “messages”, which is third-person plural, so
it can't take the -s suffix.
closesodoo/odoo#129468
X-original-commit: 0d10cfeaa56d5df23df05f436d353978043f4a71
Related: odoo/enterprise#44509
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
A new validation was recently added to prevent importing
reserved quantities on stock move lines, to prevent inventory
discrepancies [1]. However, such validation inadvertently introduced
another issue, which is now, if the reserved quantity is not filled with
0, the new validation is triggered.
This commit fixes the above issue by not requiring the reserved quantity
to be provided.
In addition, a typo is fixed in the error message:
"it is not allow" -> "allowed"
[1] odoo/odoo#119201
X-original-commit: 79f825537aa6bed8cbcd7d7edab07ea0cb80a7cd
Part-of: odoo/odoo#123287
Use case: Create an import file for a picking with stock.move.line
directly in it and add some reserved quantity on the stock.move.line.
The import of stock.move.line is not possible directly via a
stock.move.line menu but it still possible on a picking or
mrp.production import. However the create does not expect that and never
reserve the quants. So it result with quant <-> sml inconcistencies in
the data and the error can not reserve more than you have in stock.
opw-3277938
closesodoo/odoo#122156
X-original-commit: 3e78316a51f2cb8d347af1b87abcdcb775107115
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Steps to reproduce the bug:
- Connect with the company A
- Create a consumable product “P1”
- Create a receipt transfer with this product
- confirm the transfer
- Come back to the product form
- limiter le produit que a la “Company B”
Problem:
no user error triggered
Go to inventory > operation > transfer: a Traceback is triggered
Before this commit, there is no verification while changing a product's
company for consumable. That can lead to an issue where some operations
cannot be done because of access errors. To avoid that, this commit
prevents to change the product's company if some move lines for this
product exist in another company.
opw-3300559
closesodoo/odoo#120983
X-original-commit: a6666de7f492f9f94abc23a080134dd473d0dddc
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
before this commit, there is typo in unit of measure
after this commit, the typo will be corrected and
unity of measure will be updated to unit of measure
closesodoo/odoo#116764
X-original-commit: 11b89fcffe748e6119648dbc32594f0c0bdcf064
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Since #91640, the locations on stock picking are editable except in `done` state. This can leads to misunderstanding if some stock move lines
are already created. The locations on stock picking act as default
values for stock move/ stock move lines. Validating a picking will
always use the location set on stock move lines even if those ones
differ from the picking. This commit adds a simple error message in
to address this situation.
Close#113486
opw-3148993
closesodoo/odoo#114868
X-original-commit: 3eeab703f4e36723eae6005cf4b966f20f1e62dd
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
After unlock a picking/MO, it's possible to change the qty_done of a
cancelled move. This change won't have any result on product's stock.
In this commit, we raise an error when user changing cancelled moves.
We advise user to create a new line instead.
Task-3116125
closesodoo/odoo#111910
X-original-commit: c6c3e5984c3fa0fc1810ae490bd4ce10390eebd8
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Before this commit, there is no verification while changing a product's
company. That can lead to issue where some operations cannot be done
because of access errors.
To avoid that, this commit prevents to change the product's company if
some quants for this product exist in another company's location.
How to reproduce:
- Have at least two different companies (let say CompA and CompB);
- Create a new product who belong to no company;
- For this product, add quantity on hand in a CompA location;
- Now, change the product's company for the CompB;
- While selected only the CompA, go into the Inventory Adjustments and
try to create a new inventory adjustment for the CompA location with
this product's quant -> Access Error.
opw-3095984
closesodoo/odoo#110810
X-original-commit: 46987e13f35dc140869c58f6c5a09d9c542c3ae5
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
The `product.product` method `_get_rules_from_location` can call itself
in case `_get_rule` returns a rule using the "Trigger Another Rule"
supply method. But if this rule cannot trigger any other rules,
`_get_rules_from_location` will continue to call itself endlessly until
it reach the recursion's limit, causing a traceback.
How to reproduce:
- In Inventory Configuration, enable "Multi-Step Routes";
- In Configuration > Rules, create a new rule with the following config:
- Action: Pull & Push
- Operation Type: Internal Transfers
- Source Location: same location than the Destination Location
- Supply Method: Trigger Another Rule
- Route: Receive
- Insure the created rule is the only one used by its route;
- Insure there is at least one product who needs to be ressuplied;
- Click on Operation > Ressuply --> traceback.
opw-3068546
closesodoo/odoo#110446
X-original-commit: 511eebf7de4b751b776e7b2d1b1d15a08c53171b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
in purchase_requisition and stock module, when deleting a requisition and move, the raised warning says,the deletion can be done only in draft moves, where us the deletion is allowed for the cancelled records also.
improving the user error message to include the cancelled records in the message.
closesodoo/odoo#110340
X-original-commit: b71d298dabb4436182c0eb516d5a7b7e76fca437
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Currently if you require internal transit pickings between warehouse,
it's not possible to use security days in order to plan them and
receive products on time (e.g the second warehouse need times to
manufacture them).
Also the deadline are impacted by security days, so it's hard to
do at the same time replenish on order an use the orderpoints.
(either you see them late in orderpoints or they are plan way to
early in replenish on order process)
To avoid this kind of issue this PR introduces a visibility days
global on the orderpoint. It's call `stock.visibility_days`.
It will add the number of days in the orderpoint forecast date but
it doesn't impact the documents (PO, MO) planned dates.
It could for example always show the quantity in 1 years if people
don't need the just in time feature and don't care to store for a
long period of time.
closesodoo/odoo#110303
X-original-commit: 24816bfee9825fecd60bd24a92d1496f30522b8e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
- Install stock
- Activate storage locations
- Switch to French language
- Go to stock/analyse/emplacements
- Select all locations
A javascript traceback pops up because the names 'Set' and 'Count Sheet'
are not translated, therefore we use _t function to translate the terms.
opw-3113275
closesodoo/odoo#109261
X-original-commit: 719a6e6223bbde3cdeb0ade5665d95681c436521
Signed-off-by: Tiffany Chang <tic@odoo.com>
This reverts commit 3ebe1185a4.
The code ECC200DataMatrix already exist in reportlab (that is already a dependance).
Some differences:
- ECC200DataMatrix only supports a Type 12 (44x44) C40 encoded data matrix.
(214 alphanumeric characters and 14 to 27% of error correcting rate)
- pylibdmtx support more type and add a default to 24x24. So it means a
(52 characters and 20 to 35% error correcting rate). It's also smaller
to display.
We consider the gain too small compare to maintain an extra lib.
It also fix blured datamatrix in stock report if they contains too much
data.
*If you want to test 001234560000000018 is a valid sscc for package
closesodoo/odoo#106620
X-original-commit: 54ef19f41ffc4a6f715474b65a4183a7fa75feea
Related: odoo/enterprise#34422
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
currently odoo is allowing to create a scrap order record with 0 quantty, which doesn't make sense and also if it is allowed, user wont be able to edit change the quantity later. currently zero quantity is not blocked by _check_positive_qty_done on stock.move.line. And it doesn't make sense to scrap 0, thus preventing the same by raising a validation
closesodoo/odoo#105752
X-original-commit: eb899fe8dda12d0f0e4ae515bb01e65981f4fbcd
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
- Create a product and complete a sales order.
- Then try to change the product type.
- The following message is shown:
"You cannot change the products type because it is already used in sales orders."
However, we can close the message and save.
Problem:
If some sales were already made, it should not be possible to change the product type.
There is a warning message on the onchange but it's not blocking.
This causes inconsistencies between the quantities and value shown in the quants and in the valuation layers.
Solution:
Raise an user error when trying to save the changes.
opw-3000886
closesodoo/odoo#105496
X-original-commit: 1b468ad100960cbd6940a24fbfaeeae4f01994de
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
"Storage Category Capacity" menu appears as long as the debug mode is
on, even if the "Storage Category" isn't selected in the settings and
the corresponding group isn't set.
Since this menu is accessible from the Storage Category form anyway, we
move the link to this table in the settings (where we can safely display
it in debug AND with the setting activated), and we remove it from the
menu.
Part of task-2985735
closesodoo/odoo#102422
X-original-commit: 8b2ca9743af423dbe89c4992f462d36d434a60a9
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Current behavior:
If the UoM of a product is not 'units' (e.g 'kg') and tracked by lot.
When trying to print labels 'per unit', some users except one label printed
per 'kg'. But it will actually print one label per lot.
This is not a bug so we are just adding a tooltip to make it clear that only
one label will be printed for lots using UoM different from 'units'
Steps to reproduce:
- Create a product tracked by lots with 'kg' as UoM
- Create a purchase order for 5kg of this product
- Validate the PO and receive the products in 2 lots
- Print the labels "Lot/SN Labels" > "One per unit"
- Confirm, the PDF shows 2 labels
opw-2941942
closesodoo/odoo#98812
X-original-commit: 5b2eb07d3831406146d70150e3a9f61fa3aca7c3
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Only for terms containing Credit Note and expenses
closesodoo/odoo#97840
X-original-commit: 1754b094a66476a0bdb29fe60dc5583c03336c3f
Related: odoo/enterprise#30262
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When moving some products between two warehouses thanks to an internal
transfer, the forecasted inventory becomes incorrect
To reproduce the issue:
1. In Settings, enable "Multi-Warehouses"
2. Let WH01 be the existing warehouse. Create a second one WH02
3. Create a storable product P
4. Update the quantity of P:
- 3 in WH01/Stock
5. Create a planned and internal transfer T:
- Source: WH01/Stock
- Destination: WH02/Stock
- Ignore the warning
- Operations:
- 1 x P
6. Mark T as todo
7. Open the Forecasted Inventory:
- Filters:
- Forecasted Stock
- Product: P
- Group By: Warehouse
Error: The report is incorrect, it says there are 3 P in WH01 and 0 in
WH02 (should be 2 and 1). It becomes worst if T is done (the quantities
in the past become incorrect)
We should be able to move a product between two warehouses thanks to an
internal transfer (so the warning of the step 5 should be removed).
Moreover, the `report.stock.quantity` should consider that use case.
When processing a stock move, the SQL view translates it as an in-move
or out-move for a specific warehouse. For instance, if the SM comes from
a warehouse and goes to a location without any warehouse (e.g., customer
location), the SM is considered as an out-move. But here is the issue:
in case of an inter-warehouse SM, both source and destination have a
defined warehouse.
Therefore, we need to:
- Duplicate the inter-warehouses SM (so we have one in and one out)
- Fake the values (no destination warehouse for the out move, no source
warehouse for the in move)
Also, before duplicating all SM, we filter out some useless SM:
- Draft and cancelled ones
- SM done more than 3 months ago (because the report only works for [-3
months; +3 months])
Considering some tests:
(SM are confirmed. Each test has been repeated 5 times to get an
average)
| | |
|:-------------------------------------:|:--------:|
| 5000 SM, 0% inter-wh, without the fix | ~715 ms |
| 5000 SM, 0% inter-wh, with the fix | ~710 ms |
| Impact | 0.99x |
| | |
| 6666 SM, 0% inter-wh, without the fix | ~911 ms |
| 5000 SM, 33% inter-wh, with the fix | ~999 ms |
| Impact | 1.10x |
| | |
| 7500 SM, 0% inter-wh, without the fix | ~1004 ms |
| 5000 SM, 50% inter-wh, with the fix | ~1097 ms |
| Impact | 1.09x |
The impact is not that significant
OPW-2752017
task-2822157
closesodoo/odoo#91772
X-original-commit: b1efc0243bbf886bbef42a32587f4a818fa34e64
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce the issue:
1)Inventory > Configuration > Settings > Activate "Reception Report"
> Activate "Show reception report"
2)Choose a non english language
3)Sales > Choose SO > Delivery > Allocation
4)Click on the Assign/Unassign equivalent in the new language
Current behavior:
The word in the Assign/Unassign button is in english
Expected behavior:
The word in the Assign/Unassign button is in the new language
Explanation:
When clicked the button starts a function in js that changes the
button text context without translating the new text. We also modify
the text in javascript and the problem is solved.
Issue 2:
The button had fixed size specific to the english language, if a longer
translation in another language was used it was cut leading to make it
unuderstanble in some languages (e.g. german).
opw-2827247
closesodoo/odoo#90705
X-original-commit: 260f433f5600e568db59c82a9c2fc807c1204b5f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
When using an internal transfer to move some products between two
warehouses, the forecasted inventory becomes incorrect
To reproduce the issue:
(Let WH01 be the existing warehouse)
1. In Settings, enable "Multi-Warehouses"
2. Create a second warehouse WH02
3. Create a storable product P
4. Update its quantity: 1 x P at WH01/Stock
5. Create a planned internal transfer (the warehouse does not matter):
- Source: WH01/Stock
- Destination: WH02/Stock
- Operations:
- 1 x P
6. Mark the transfer as Todo
7. Consult the Forecasted Inventory report:
- Filters:
- Forecasted Stock
- Product: P
- Group By:
- Warehouse
Error: The line for WH02 is missing and the line for WH01 is incorrect
(qty is 1 for next days while it should be 0)
The report used (`report_stock_quantity`) does not handle this transfer.
Because both locations (source and destination) are defined, the SM is
not considered as an in-move or out-move:
https://github.com/odoo/odoo/blob/07f0ffad6ecc08f4165902db45ae96e4b41199e8/addons/stock/report/report_stock_quantity.py#L38-L43
Moreover, it would be hard to change the SQL view to generate two lines
(one 'in' and one 'out') from the same SM (the internal move).
The graph on the forecasted report of product P is also incorrect (it
uses `report_stock_quantity` to get the data, so if the user selects a
specific warehouse in the filters, the result will be incorrect)
So, the user should only avoid to transfer some products between two
warehouses if the internal transfer is a planned one.
OPW-2752017
closesodoo/odoo#87965
X-original-commit: 7f56063f6fe63a70d3e23b9c5fb486cc0958dd3e
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
It is sometimes impossible to unbuild a product because of decimal
values.
To reproduce the issue:
(Enable debug mode)
1. In Settings, enable "Units of Measure"
2. Set the decimal accuracy of "Product Unit of Measure" to 4
3. Set the rounding precision of "Units" to 0.001
4. Create two products P1, P2
5. Create a BoM:
- Product: P1
- Quantity: 3
- Type: Manufacture
- Components: 5 x P2
6. Process a MO with 3 x P1
7. Create an unbuild order UO:
- Manufacturing Order: MO
- Quantity: 1
8. Unbuild
Error: An error message is displayed "The quantity done for the product
"P2" doesn't respect the rounding precision[...]"
At some point, for each SM associated to the UO, the modules uses the
value of `product_uom_qty` to write the done quantity of the SM. The
rounding of `product_uom_qty` is based on "Product Unit of Measure" so
the component's SM has its quantity equal to `1.6667`. Moreover, writing
the done quantity trigger the creation of the associated SML. As a
result, the SML has its done quantity equal to `1.6667` while the
rounding of the associated UoM is `0.001`. When calling `_action_done`
on such a SML, it will raise an error because the value doesn't respect
the rounding.
Side note: the error message is incorrectly written, the indents in the
file are displayed on the front-end.
OPW-2710038
closesodoo/odoo#83369
X-original-commit: c11d772f39179c5dec5eb431b6f4bc02c680643a
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Fix the inconsistency of product_{min,max}_qty in orderpoint. Both have
different tooltip saying that the reordering rule would trigger if :
- min: forecasted_qty <= product_min_qty
- max: forecasted_qty < product_min_qty
As the tooltip of the product_max_qty is in fact correct, we adapt the
tooltip of the product_min_qty to match the reality.
Task-2656397
Part-of: odoo/odoo#79523
Previous task: odoo/odoo#61287 improved warnings for when using a
duplicate SN, including an auto-update of the source location when
appropriate. Unfortunately the auto-update is too risky when registering
a subcontracting SN tracked components.
Instead, we no longer update the source location when in a
subcontracting situation and update the warning message to match the
expected flow to fix the issue.
closesodoo/odoo#79334
Task: 2669180
X-original-commit: a430c4d7d6e2a02ef9b3905b554a779fc1643bcf
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
WO are released in confirmed state, but the help message says that they are released in draft.
opw-2609040
closesodoo/odoo#78954
X-original-commit: 3244944d0b6ccf7d18d8bb852183d14282674097
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
"Material Availability" vs "Component Availability" label means
the same thing but it shouldn't.
- Rename these and add a help string for both fields.
- Change decoration to be green if the MO Readiness is
'ready'.
- The logic of `_compute_*_availability` doesn't take in account the
'ready' `(reservation_)state` to distinct clearly both fields
(`(reservation)_state` vs `*_availability`)
task-2668922
closesodoo/odoo#79033
X-original-commit: acc385137a6a59f3632d91a7fcabd5ab42e8bc7f
Signed-off-by: Tiffany Chang <tic@odoo.com>
Louis (wil)