- Fix the issue of the added test.
- Also batch the `push_apply` + `_action_confirm` by doing confirm
in BFS instead of DFS. Improve a lot the performance when
the _action_confirm is on batch.
closesodoo/odoo#61567
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This commit updates the description_picking on stock moves once the
picking type is changed. This is needed to merge stock moves at
confirmation. The description_picking field chosen on the merged move is
the 'minimum one'. Empty string will always be chosen that way, so we
lose the information.
closesodoo/odoo#60762
X-original-commit: a3dad0f892b5394124763ceb13305fca745c95b9
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Steps to reproduce:
* In Inventory, activate multiple warehouses and storage locations, multi-step routes, Delivery packages
* On the main warehouse, activate 3 steps delivery
* Create a stockable product A
* Update quantity on hand: 100 units in a package PACK1 in Stock/Shelf 1
* Create a new Pick transfer with one move: 120 product A
* Set the transfer as todo and check availability: a move line for the 100 units from PACK1 is created
* Edit the move line: set a destination location, **change the result package to PACK2** and set a qty_done
* On product A, update the quantity on hand: add a *new* package PACK3 of 20 in Stock/Shelf 1
* On the transfer, click on check availability
Current behavior:
* A new move line is created for the 20 units from PACK3 to PACK3: ok
* The move line edited before for the 100 units has its result package **reset to PACK1**
Expected behavior:
* A new move line is created for the 20 units from PACK3 to PACK3: ok
* The move line edited before for the 100 units has its result package kept to **PACK2 as edited by the user** who decided to open the package already
Short analysis:
At the end of `StockMove._action_assign()`, the method `StockPicking._check_entire_pack()` is called. For each package moved by a move line, this method checks if the package is entirely moved (sum of quants == sum of move lines). The check is done by `StockPicking._check_move_lines_map_quant_package`. When the sums match, the package level of the move lines is created or updated. When it happens, it writes the package in the `result_package_id` of the related lines.
It should not change the result_package_id if it was already set.
Thinking further, maybe it should not consider lines with a `qty_done` in `_check_move_lines_map_quant_package`: users already picked these lines, if they decided to empty or change the `result_package_id`, a new check of availability for the remaining quantities should not change these lines.
opw-2346608
Fixes#58491closesodoo/odoo#60025
X-original-commit: db262912eb716aed1c42be8a9d59c25bdfa400e0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Consider move uom different from serial product uom
to set up move lines with product uom
closesodoo/odoo#59986
X-original-commit: ee966998fa986936a0407676bb4d54f61c7fce1f
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
This commit does 3 things:
1. When 'action_confirm' is triggered in a manufacturing order, any
'move_raw_ids' (components) that are unable to be fully reserved
when `action_assign` is triggered will be checked for an automatic
reordering rule (RR). If a rule exists it will be auto-triggered.
This includes subcontractor manufacturing orders. Relevant test
updated to match this.
2. When a MO is completed, auto check if there are corresponding
confirmed stock moves that can be populated by the completed products
and trigger their 'action_assign' to reserve the completed products.
3. If a new move line is added to an already confirmed MO, then do same
auto-RR check/trigger. (note will occur for pickings without extra
code since `stock_picking.action_confirm` is triggered again in this
case.)
This reuses similar logic as odoo/odoo#52433 from task 2244230.
Originally this was done in the `action_assign`, but has been moved to
`action_confirm` so as to imitate the now archived MTO process with RR.
Overlapping logic has been moved into stock_move for easier reusability.
Note that this now means editing existing moves' `product_uom_qty` (i.e.
Demand) will not have a flow to auto-trigger their RR.
Subcontracting test updated to match + new mrp test added for this new
feature.
closesodoo/odoo#57334
Task: 2322496
X-original-commit: 2688cd1bae489b1dec8862f4de727ac20514844c
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Change the default rouning digits of all UoMs to be two, also change the
decimal.precision of UoM to be two. Adapt all the tests.
Also to avoid hardcoded digits in `should_consume_qty` widget.
PR #56000
X-original-commit: 460ec0402a2352a5b179d81935f7230f6bc97cb7
Mainly transifex issues but also some errors found through 'grep' checks.
Fix typos and obscure english strings in xml contents, fields strings/helps, some docstrings, ...
ensuring correct translations base (and fallback when translations isn't available).
closesodoo/odoo#57276
X-original-commit: 4214f05d454bca2b60fda3a288d529c098e84f77
Related: odoo/enterprise#13053
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.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
PURPOSE
Lessen use of mail-specific calls and variables
SPECIFICATIONS
Use mail_new_test_user tool in tests, lessening use of mail-specific context
keys in tests.
LINKS
Task ID-2326281 (context keys use cleaning)
PR odoo/odoo#56631
PR odoo/enterprise#12707
X-original-commit: 910559c092dc7dfa00b91339a5423e16cd4668e1
This commit sets up the logic and adds the button for "Put in Pack"
action that already exists in stock.picking. Reuse/extension of logic
from stock.picking reused where possible, including extension of pack
wizard to handle products with different destination.
Note that logic to handle "Delivery Packaging" wizard when "Delivery
Methods" is active was purposely not extended to work correctly in batch
pickings due to complexity of adding in a new module just to handle
conflicting carrier_ids across pickings in the same batch. It is
expected that this use case will not occur except in case of user error.
Additionally, stock.picking implementation of 'put_in_pack' method has
been renamed to 'action_put_in_pack' to have consistent naming (and
support enterprise level code).
Part of "1. Improve Batch Pickings" specification of overall barcode
improvements task.
Task: 1884520
Enterprise PR: odoo/enterprise#12086Closes: odoo/odoo#55096
Allow to add serial numbers as tags on the move in production order and
stock picking. The purpose is to earn time for database with
only tracking installed.
Also when only create_lots is checked on picking type. New lots
could select existing lot and an onchange trigger a warning if
it's used.
closesodoo/odoo#55883
Task: 2280985
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- The deadline of MO generated via procurements is calculated differently.
Now, it doesn't take anymore in account the manufacturing_lead
of the company (Security Lead Time of MO). The computation of planned date remains unchanged.
- The date_expected fields was duplicated with the date fields
except when the move was done. Merge both fields.
The only information lost is: we can't know what was the
scheduled date before processing move (`state` == done).
Indeed, the date becomes the actual move processing datetime.
- The `date` in `stock.picking` field contained the time of
(purchase) order `date_order` (`purchase.order`).
This field is was wrongly used in the kanban view where we
expected to see date_planned instead. Also, the `_order` used
this date instead of date_planned too.
- The `delay_alert` is activate independently of stock rules.
Then it is now activate in all case.
- Remove the auto-reschedulting process of stock move via
the stock rule (`propagate_date` and `propagate_date_minimum_delta`).
Replace it by a automatic deadline date (`date_deadline`) propagation.
The deadline is the promise done to/by vendor/client (SO/PO)
then it is a readonly fields on picking/move and MO.
- Now the Scheduled date (`date`) of stock move is never propagate
and it is only related to the Scheduled date of
related document (MO or picking).
- Now when a move is created from procurement (sale),
`date_planned` = `date_deadline` - `security_lead`.
- The `delivery_date` of sale is no editable after confirmation
and propagate as the deadline to related stock move linked to order_line
- Adapt filter and decoration of MO and picking.
- Because we are the client in case of purchase (PO), the promise of vendor
can be not respected. Then we add the lead security to the deadline
(inverse the sale order logic) of PO picking (promise reciept date
+ security lead) to match with the replenishment.
task-2246665
Adds the Replenishment Report, a printable report on product variants
and product templates. This report displays all draft and planned moves.
It has also the purpose to be overridden to handle purchase and sale
lines, and product's consumptions/productions of manufacturing orders.
Documents listed in the report can be accessed by clicking on their name.
task-2058495
Co-authored-by: sle-odoo <sle@odoo.com>
1) Create a stockable product > Add some quantities on hand
2) Edit this product > set it as a consumable or service
3) Create an inventory adjustment on all products
Error will raise "Something went wrong! You can only adjust storable products.
This occur because when switching product type the available quantity
was not cleared, so it will get in the next inventory, but only storable
products can have inventory. So the product should to have no
quantity left before switching type
opw-2300478
closesodoo/odoo#55062
X-original-commit: be17e31307070498ba9ac7dc594443730caa7404
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
1. When reservation can't be done for some products, we automatically
evaluate their reordering rules and create the corresponding
replenishment document.
2. When receiving products in stock, automatically check if some stock
moves are available and assign them.
Task 2244230
PR #52433
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Write is overridden on reserved move lines to make sure the quants are
correctly updated. It is divided in two parts: if you update the reserved
quantity and if you update a characteristic. If somehow both are updated
in the same call (which doesn't happen in the standard interface), then
the quants are unreserved two times, which is wrong.
This issue showcased by [0] and on databases where the reserved
quantities are made editable by customization.
We grouped the two update in one, such as the TODO indicated us since a
long, long time.
We removed `result_packaged_id` from the trigger because it should not
impact the reservation whatsoever.
We needed to remove a tricky logic in the stock move's backordering part
but it was fishy anyway.
[0] eac8c06e2233
closesodoo/odoo#53928
X-original-commit: 507101434f9221f2cfa6de66e1952676fff322fd
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This commit makes it so products can be replenished without any other
module. This is achieved by adding a "pull" rule to the default receipt
route generated when a warehouse is created. "Pull" rule is added to 1-,
2-, and 3-step receipt routes. Previous to this commit, an additional
module (e.g. purchase, mrp, etc.) was needed for a pull rule to trigger
with the existing receipt route rules. Replenishments can be triggered
via "Replenish" button in product form, recording rules (auto trigger),
and replenishment (manual trigger).
Additionally, this commit makes it so when other modules (mrp, purchase)
that handle replenishment are installed, this additional "pull" rule is
removed from the default receipt route to prevent undesired behavior
(e.g. MTO manufacturing components magically being received from no
where). Unfortunately this means 2 undesirable situations:
1. If a user adds adds/changes rules to the receipt route and then installs
mrp or purchase then their additions/changes will be removed.
2. If a user removes either (when only 1 installed) or both of these
modules then stock module will again not be able to replenish as the
pull rule will not be re-added to the receipt route.
It is expected that these 2 cases do not need to be handled in most
cases or can be handled by advanced users.
Stock tests have also been updated to accomodate this new pull rule.
Specification 4 of overall inventory onboarding improvement task.
Task: 2220129
Related Enterprise PR: odoo/enterprise#10719
Before this commit, when a backorder is created, it was automatically
reserved. It is no more the case. Now user have to reserve it manually.
The reason is, when a user doesn't delivery all expected quantities, it
could be because there is no enough quantity in stock, or the user
doesn't want to delivery all. In these cases, it doesn't make sense to
reserved it directly.
task-2181611
Check backorder is divided in 3 blocks:
1) quantities on move lines linked to a move
2) quantities on move lines without moves nor products but with a
package
3) quantities on move lines without moves but with a product
1) added quantities in the move's uom, 2) added quantitis in the product
uom, 3) doesn't seem to be used (and shouldn't be). Clarify all of that.
task-2239964
closesodoo/odoo#49790
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This restricts the attributes of a BaseModel instance to `env`, `_ids`
and `_prefetch_ids`. This way, one can only assign fields on a record;
other assignments are programming errors.
This also reduces the memory footprint of records from 168 to 64 bytes
(-62%), and makes their instanciation faster.
closesodoo/odoo#51075
Related: odoo/enterprise#10529
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
New report to easily order missing products in each warehouse.
Orderpoint have a new type: 'manual'. Manual orderpoint are not
trigger by the scheduler but the user could create replenishment
from the report directly. The report use the forecast report in
order to detect missing quantity for today (it does not search
depending the lead time for each product warehouse due to lake
of performance). It compares missing quantity with incoming RFQ
and other ongoing orderpoint. If it still missing a new entry
for replenihsment is created (it's also automaticaly deleted if
the replenihsment has been done another way).
Task: 2161378
The generation of SN is incorrect with the following initial sequence:
`BAV023B00001S00001`.
Indeed, the sequence generated is: `BAV023B00001S`, `BAV023B00002S`.
This occurs because the same digits `00001` appear more than once.
opw-2230913
closesodoo/odoo#49408
X-original-commit: b3369bc230160d6cafec77eed0e756c6f1c576d9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Currently when the warehouse is created the picking type are created
with a fixed barcode that contains the warehouse code. Later, a
warehouse's code modification will not impact the barcode on the
picking type. However when a company is created the warehouse is
also created with a default code. It's easier to modify all the
barcodes when the code is modified rather than update picking type
one by one. We expect users to setup warehouse configuation before
starting to customise its components so it should not be problematic
but it implies that a late configuration could impact small
configuration on locations and picking types.
Before this commit the demo delivery WH/OUT/0005 is plan then validated.
But as this delivery is the one used as example in the barcode PDF, it
could be usefull for demonstration to keep it as to process.
So, this commit keeps it only as ready, and also increases the stock
amount of Desk Combination to be able to process this delivery without
any issue.
task-2199747
closesodoo/odoo#48320
X-original-commit: 652ee46e8adc35bae4f89bf9802f12bd1c424c8d
Related: odoo/enterprise#9474
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Currently the quantity outside warehouse in the forecast report is erroneous.
It only takes the quants and not the stock.move incoming and outgoing for those location.
So the qty is only correct for the current datetime.
Remove this functionality and remove the filter 'warehouse is set' since it's always the case.
closesodoo/odoo#47997
Task: 2217047
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
PURPOSE
Keep consistent behavior of the stat buttons and the different stock
reports when archiving a product
SPECIFICATION
Currently, you can archive a product but the behavior of the different
stock reports, stat buttons isn't coherent afterwards. Here are the
different behaviors that should be improved:
1.Keep quantity on hand and forecasted quantity visible (in the stat
button + when opening it)
2.Automatically (un)archive RR and BOM if the product is (un)archived
3.Valuation report: show the archived products without the "archived"
filter (behaves already this way in the inventory and forecast reports)
4.When a product has been archived and still has quantity in stock,
include it in inventory adjustments for which counted quantity = default
to stock on hand (dont do so for archived exhausted products).
Also, revert #47478 since we don't have active field.
LINKS
Task 2178269
PR #45586Fixes#41634
Related: odoo/upgrade#811
Related: odoo/enterprise#8513
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Let's say we have a chain of move
wh1 - intercomp transit -> intercomp transit - wh2
The second move will be reserved according to what the first move
brought since they are chained. This behavior resulted in rev[0] which
tries to work around the ir.rule limiting the access of stock.move and
stock.move.line records in multi-company environment.
This patch wasn't perfect since, if the first move brought a lot, the
second move will reserve this lot and it will result in another access
error since the lot will still have the company of the first move.
We fix this by implementing the following logic: receiving from another
company should behave the same as receiving from the supplier, no
reservation is applied. We fix this by marking the inter company transit
as `_should_bypass_reservation` and we break the move chain if the
pull/push rule create an intercompany chain.
[0] 6ff34073153767d449804669f31e26c04de0a670
closesodoo/odoo#45601
Task: 2160847
X-original-commit: 67b45da9d877a5a1bb9adb3ce14051e01f67045f
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Install MRP and Purchase
- Configure the rule 'Stock → YourCompany: Production (MTO)' with:
Supply Method: Take From Stock, if unavailable, Trigger Another Rule
- Create a product AB with route 'Manufacture'
- Create products A & B with routes 'Buy' and 'Replenish on Order
(MTO)', set a supplier
- Create a BOM for AB with:
Product A: 2.0 Units
Product B: 3.0 Units
- Create a MO for 1.0 Unit of AB, 'Mark as Todo'
No RFQ is created for A & B while there is no stock available and a
supplier is set.
This is because the 'MTSO' logic is located in `_run_pull`, which is
never called in this use case since no procurement is created.
We need to apply the same logic in `_adjust_procure_method`, which is
called at MO confirmation.
opw-2189694
opw-2194739
X-original-commit: 9ae3b3e8d2694f5560913682824fd10e60de14a4
0. Create 2 Products A & B
1. Open Inventory > Configuration > Settings and flag the following
checkboxes:
Delivery Packages
Product Packagings
Storage Locations
Multi-Step Routes
2. Go to Inventory > Configuration > Warehouses and open YourCompany WH
3. Set 'Incoming shipments' to 'Receive goods in input and then stock
(2 steps)'
4. Go to Inventory > Configuration > Operations types.
5. For 'YourCompany: Delivery Orders' and 'YourCompany: Internal
Transfers”, flag the following checkboxes:
Show Detailed Operations
Move Entire Packages
6. Go to Inventory > Configuration > Locations and open 'WH/Stock'
7. Edit and create a new 'Put Away Strategy' called 'Stock'
8. Add a new rule:
Product A, with Location 'WH/Stock/Shelf 1'
Product B, with Location 'WH/Stock/Shelf 2'
9. Go to Inventory > Operations > Transfers to create a new picking.
10. Select 'YourCompany: Receipts' as 'Operation Type'
11. Under Operations, add a new line with product A and an 'Initial
demand' of 20
12. Save and 'Mark as to do'
13. Enter in edit mode and under 'Detailed Operations', set a quantity
of 11.0 on 'Done' and click on 'Put in Pack'
=> A new pack is created
14. Repeat 13 with a quantity of 9 to create a new pack
15. Save and click on 'Validate'
16. An existing 'Internal Transfers' with the two created Packages
having following properties:
From: 'WH/Input
To: 'WH/Stock/Shelf 1'
At this point, the behavior is expected.
17. Cancel the picking created
18. Create a new picking:
Operation type: 'YourCompany: Internal Transfers'
Source Location: 'WH/Input'
Destination location: 'WH/Stock'
19. Under Operations, add two new lines using the packages os step 16.
20. Save and 'Mark As To Do'. The two packages have the following
properties:
From: 'WH/Input
To: 'WH/Stock'
We can see a difference in behavior. The picking created from a 'Pull'
mechanism applies the putaway strategy to the package, while the picking
created from the 'Push' mechanism doesn't apply it.
We make the behavior consistent. Moreover, in case the package contains
products having different destination locations, the destination of the
picking is kept.
opw-2146583
task-2148494
closesodoo/odoo#45549
X-original-commit: 705bdaa4ae5251b05bc2bbba02f2ca561ca00bbc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
Create an immediate transfer for a receipt, add a move, set a quantity
done and due to rev[0], an initial demand is set, then
_autoconfirm_picking is called and action_confirm of picking calls
_action_assign if the location source bypasses the reservation. Set
again an inferior qty_done, the initial demand is also updated due to
rev[0] and somehow the system tries to write on a now unlinked move
line.
fixes
- never reserve an immediate transfer
- never update the initial demand if the move is reserved to fix the
existing databases.
- adapt _compute_state so that immediate transfer moves considered
reserved so that they're always "ready"
- adapt the test that was working on an immediate transfer picking and
setting the initial demand while it's not possible through the
interface, the user can only set the done quantity.
[0] 8303b1aclosesodoo/odoo#45317
X-original-commit: 357e0a862744f1bc23a9643a1822d2ee4a2eb7a2
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this patch, validating an unreserved move of a dozen while 12
units were reserved resulted in a quant with 0 unit as quantity and 11
units as reserved quantity.
closesodoo/odoo#45132
X-original-commit: bf7d76a7127521ba17f29bc470c3d551cc9988d5
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When a user unreserve a picking or a move it will
drop all the linked move lines. However it could
happens that some move line already have a done quantity
and the user won't lose this information.
This commit filters move lines in order to only drop
the move line without quantity done and remove the
reserved quantity on others.
Joint work with William Henrotin <whe@odoo.com>
task-2069646
Before this commit, a move can be 'assigned' even if it has no reserved
quantity.
How to reproduce:
- For a tracked product, add some quantities for a LN/SN. Create an
another LN/SN with no quantity;
- Create a delivery for this product;
- Confirm it and check availability;
- On the move line, change the SN/LN for the one without quantity.
--> The move has no reserved quantity but is still marked as
`assigned`.
task-2171546
closesodoo/odoo#44145
X-original-commit: d5e70fa9778240b23515cea6ab1a3d0a674ac940
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Co-authored-by: sle-odoo <sle@odoo.com>
Two of the UserErrors mentioned 'quantites' instead of 'quantities' before this commit. This commit fixes the terms and the translation file.
closesodoo/odoo#43902
X-original-commit: 68a849bfb507c5fa14b869a44ea50bf88ff3ce1f
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Improve the inherited wizards of 'stock.warn.insufficient.qty' by adding
some piece of information about the quantity involved. Also
change titles to integrated the related product into.
task-2144636
Co-authored-by: Ankita Raval <anr@odoo.com>
When the scheduler runs, each orderpoint will check the forecast stock
for an infinite time. As example, if we plan a receipt of 10 products in
4 months and need to deliver 5 products next month, procurement will not
be launched since we have a forecasted quantity of 5.
In order to improve it, the orderpoint will compute the total lead days
from rules, suppliers/production delays, security days,...
Those lead days will be added to today in order to know at which date
the forecast stock should be checked and trigger the replenish document
for today in order to be delivered at the correct date.
Task: 1849912
Currently orderpoint run one request at a time. However it's not
efficient since compute are some private methods could be executed
one time in batch instead of record by record.
The strategy in order to improve it is:
- Still cut the orderpoints in batch of 1000 (usefull when using a new
cursor with intermediate commit)
- For each batch of 1000, create a list of procurement values and run
them in batch (commit a2a6b099a4 for more info)
- Each time a procurement exception is raised, catch the failing
orderpoint and rollback to the state before run. Remove the failing
order point from the current set and run it again.
- run method try to catch a maximum errors by continuing to process even it
finds error in order to stack them. It would avoid to run the same set
again and again each time an error is raised.
test_orderpoint_1 took 975s before this patch and 100s after.
Task: 1849912
Remove the "manual" system alert and replace it by a date field, `delay_alert_date`.
This field is computed in the method `_delay_alert_check` when we write on the date of a stock move.
The method `_delay_alert_check` look to the next stock move and to the previous know to
check if they will be late or not.
If a stock move will be late because of one of the previous stock move, `delay_alert_date`
will contains the minimal date that the stock move should have. Otherwise, `delay_alert_date`
will be False.
Task #1970595
Co-authored-by: sle <sle@odoo.com>
Before this commit, we can't use the Generate and Assign Serial Numbers
on already existing move line. It always creates new one, even if the
picking type use "Pre-fill Detailed Operations".
Now, it will edit existing lines, except if we ask to generate more SN
than we have unassigned move lines, or if the picking don't use the
"Pre-fill Detailed Operations" option, in which cases it will still
create new move line with the generated SN.
Also, before this commit, paste a list of serial numbers to assign them
on multiple move lines in once work only with creation of a new move
line for each serial number.
Now, it's also work with existing move lines.
Finally, some code shared the same logic in `stock.move` in the move
line onchange method and in the `_generate_serial_numbers` method.
Moves this code in a new method, `_generate_serial_move_line_commands`,
and call it in the two previous methods.
task-2150561
closesodoo/odoo#42316
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Create a move line from stock to shelf1 with PACK1
- Create a move line from stock to shelf2 with PACK1
- Validate
It should be be blocked. The contents of a package should all
be in the same location since the pack itself is in a location.
It's due to commit 78d6f46 that fix a rounding error.
However it should check for quants that have quantity since they
represents the package content.
closesodoo/odoo#42134
X-original-commit: 78fba949790f2b1ecd3ba1bf60fb34c30d17769e
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
In the inventory adjustment form, readd (remove in 13.0)
the option to include exhausted product.
task-2115194
closesodoo/odoo#41239
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
followup of rev [0]
If these wizards are called on multiple pickings, display the list of
the pickings that could be impacted and allow to select which one should
be impacted.
We also adapt the sanity checks at the start of `button_validte` in
order to specify the concerned pickings if needed. We do not enable the
multi behavior for batch at the moment, so it's only enabled for the
validate multi in the list view.
[0] 6ab4b0d496
task-2069646
closesodoo/odoo#41497
X-original-commit: ff276c6484b138982f185ec9c832f2dbf25baaef
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This context key was used to get the valued quantities. We now have a
`quantity_svl` computed field that does this job. The test is removed,
it was showing that intercompany quants are visible thanks to a context
key but with the introduction of the on_hand filter, it is now useless
(just remove the filter)
Issue: create an immediate transfer, add a move and a done quantity, the
picking is in waiting state instead of ready.
Due to rev[0], the moves added in an immediate transfer have an initial
demand. After auto-confirming them, their state were 'confirmed' and not
'assigned'.
Solution: we force the state to assigned
[0] 8303b1a69eclosesodoo/odoo#39492
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this patch, move added in a planned transfer once it is ready are
directly marked as assigned and the reservation is disabled on them.
People found it hard to understand why the check availability button did
not appear, plus the push rules were not applied.
Now we chose to use the autoconfirm mechanism on the added move and we
don't reserve them, so the check availability button reappear.
task-2081844
Rémy Voet (ryv)