In case of multi-warehouse, the forecast button won't
take in account the related warehouse and redirect to the
forecast report of first warehouse of the company.
To ease the understand of the forecast report redirect
with the right warehouse in the context.
closesodoo/odoo#58837
X-original-commit: 53468d71b913211b38f4856f2bdb62594ee24ea8
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
This allows to restrict the reservation of a move to a specific lot, location, pack or owner
and for instance implement back the restrict_lot_id feature, among others
closesodoo/odoo#58786
X-original-commit: 8459c9dae1a83b7f1d827ee40991778c9bb9d9cd
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This commit change the _split method to return new move values instead
of create it and confirm it.
This allow multi creation and multi confirmation when every move of the
recordset are split
Task : 2076873
closesodoo/odoo#58594
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
- On `stock.picking`, remove unused `rate_picking_late` and
`rate_picking_backorders` and change the compute accordly
- On `stock.warehouse`, remove unused field warehouse_count and
remove show_resupply which can by replace by
the groups="group_stock_multi_warehouses" since
7bf064fcc160fb3f91d58e64d45e8a981865dc41
Before 9920f20e4c, the `
`_compute_product_qty` (`stock.move`) used the context to choose
the rounding method. It was remove (always used 'HALF-UP')
and replace by a comment. The rouding method used by the context was
used only on the `_split` method with always 'HALF-UP'.
Then remove rouding_method of context and remove the obselete comments.
task-2041971
Remove the json_forecast of the sale order line,
it was a duplicate of information with the qty_at_date_widget.
But improve this one:
- Use the forecasted move information in case of confirmed SO.
- Change the icon (i) to chart.
- Link to the forcasted change to target new forcasted report
(Unfortunately we loose the feature to see components product forcasted
of a kit)
- Change information print in the popover in case of confirmed SO.
Also refactor the json_forcasted of `stock.move` into multiple fields
to avoid to dump/loads for other model who needed the forcasted data.
task-2324039
closesodoo/odoo#56425closesodoo/odoo#57526
Related: odoo/enterprise#13063
Related: odoo/enterprise#13160
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
date_deadline of the stock move has been reviewed:
- Now, it represents the datetime when the operation must
be done to be in time for the uppest document (SO/PO/MO/RR).
- At the creation of stock move the date_deadline is computed in
the same way than the sheduled date expected that it is not include
security days (inverse the logic for PO).
- When we update the delivery date (or lead time) of SO (or PO).
The deadline of related stock move is updated and the delta is propagate
between origin and dest moves.
task-2324039
Before this commit, the labels for the field `virtual_available` of
product.product and product.template were different.
Unify both labels
closesodoo/odoo#45560
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In inventory report, when groupby setted and no data, the create button
will open a new form instead of create a new line. Since now our form
view is not editable, no record can be created.
In this commit, add a new editable form view to solve it.
Task 2310494
PR #55910closesodoo/odoo#57344
X-original-commit: 4a4e60c65049082855414941642dadce8b413475
Related: odoo/enterprise#13067
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Steps to reproduce:
- Create a product P with route 'Resupply subcontractor on an order'
- Let's consider a BOM for P with type 'Subcontracting'
- Create a PO with subcontractor set on that product and process with Qty > 1,
- Validate a receipt with partial Qty and no backorder
Bug:
An error was raised because no production_id was set when trying to create a mrp.product.produce
When function _action_done is called with cancel_backorder = True, the function _action_cancel is called on the new_move
with no backorder and it called the function _action_cancel defined on model stock.move in module mrp_subcontracting
This function called _action_cancel on the mrp.production record MP
And finally this function called action_cancel on model stock.move on all finish_moves and raw_moves of MP
This line unlink MP of finish_moves and raw_moves
move.move_dest_ids.write({'move_orig_ids': [(3, move.id, 0)]})
That's why production_id was not set
PS: In this way, we don't cancel a MO when it is still used by other moves.
opw:2322278
closesodoo/odoo#57346
X-original-commit: e4d22d390c8aa8edf757e36704a9e04b2b89f115
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Orderpoint qtys were not updating when an already saved stock.move has
its demand updated. This was leading to new orderpoints being created
when there is already an existing one. This commit fixes this bug by
adding the missing dependency.
Steps to reproduce:
- Create a product
- Create a delivery with the product > Mark As Todo
- Go to replenishment report (product should be added)
- Go back to same delivery > unlock > increase the existing move line
demand amount
- Return to replenishment report.
product now has 2 orderpoints instead of just 1.
Additionally this commit fixes a column mislabeling in the "Reordering
Rules" tree so that it now matches the "Replenishment" tree
closesodoo/odoo#57355
Task: 2327726
X-original-commit: 1429a7d3029fff1c6cac8fbe98b00eb931d43604
Signed-off-by: Arnold Moyaux <amoyaux@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>
PURPOSE
Clean code. Be more performance oriented.
SPECIFICATIONS
Improvements applied in this commit
* not all() --> any(not) for earlier returns;
* all([generator]) --> all(generator) to avoid unnecessary list casting.
This code construct is better managed by all;
This commit will probably not have a big performance effect on standard
production databases. However each performance and cleaning improvement
is welcomed.
LINKS
Task ID-2328619
closesodoo/odoo#56810
X-original-commit: 1cc6bb1231401ea7f501d2f5b5e9641ec8734850
Related: odoo/enterprise#12802
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The printed status should not be kept when duplicating a picking.
opw-2320680
closesodoo/odoo#56449
X-original-commit: 6938e5bf106f95149bce50fac7ed3291bd1da812
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Go to Inventory > Master Data > Products and create a Product with Tracking "By Lot"
- Go to Inventory > Configuration > Operation Types
- Edit Receipts:
* Activate "Show Detailed Operations"
* Activate "Create New Lots/Serial Numbers"
* Deactivate "Use Existing Lots/Serial Numbers"
- Go to Inventory > Overview and open Receipts
- Create a Receipt operation
In the Detailed Operations tab, if a Product tracked by lot is added,
an existing lot can be selected although it is disabled in Operation configuration.
Once saved, the selected lot disappears.
"Lot/Serial Number" column is replaced by "Lot/Serial Number Name" column.
A lot name can be entered manually. (It will create the lot at the validation)
But after validation, the lot associated to the Product is the existing lot
that has been selected during the operation creation, not the one that should
have been created from the lot name entered manually.
opw-2323093
closesodoo/odoo#56448
X-original-commit: 75add3d1496ee64d5278bc4250ac41dc4349d460
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
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>
This provides a better API to search for records by name without the
formatting part (`display_name`).
This also simplifies all the overridings of `_name_search` that no
longer need to call `name_get()`. The call to `name_get()` is done in
method `name_search` in a generic way.
- Avoid to truncate the hour/min/sec in the computation of the
effective date which is related to the `date_done`
of the first incoming picking.
- With manufacturing in 3-step (pbm_sam), the store picking
had a source document == "New". It was the case because
the `_get_move_finished_values` was call before the create
and the name is set only on create.
To fix this issue, during the `create` set the origin of all move.
- To avoid to maintain old views unused,
remove unused view of stock move.
- The computation of the products_availability json is too expensive
to be in tree view (2.5 times long with it) of picking.
It will be hard to optimize because the half the time
is due to _get_report_lines method - already in batch (on 80 records).
- Review buttons of the replenishment list to be more Odooer.
- In some cases the delay alert date was wrongly compute:
- If we new dest_move_ids of a existant move, the delay alert date
won't be compute.
- If the state (to done) and the date are save in same write call
the alert date of next move won't be reset.
To avoids these issues, refactor the alert date to be a compute stored
fields.
- To avoid any confusion between date expected in the replenishement
(in date) and the purchase order receipt date (datetime),
we put the receipt date at the middle of the day.
Also On-Time Delivery Rate computation counts
only when date are bigger effective date trunced to date.
Also used the timezone of the company by default (if not user timezone)
task-2246665
closesodoo/odoo#55379
Related: odoo/upgrade#1586
Related: odoo/enterprise#12309
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
- MO/picking/PO/stock.move have now the "same" `priority` fields
(Boolean logic: Normal or Urgent).
These models are now sort by priority first. Note that the priority field of
stock move is a technical one.
- For MO and picking, the set of `priority` field change priority of
the related stock move. The prioriry field on stock move is
used by the scheduler for reservation ('Urgent' before 'Normal')
- The Stock Replenishment Report also take in account the priority
to be consistent with the reservation.
task-2246665
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
Replace wrong usages of any(list|recordset), by any(generator)
to speed up computations, avoiding list creations and/or looping twice on a recordset
for nothing.
any([generator]) => any(generator)
any(filtered) => any(generator)
closesodoo/odoo#55768
Related: odoo/enterprise#12360
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Enable MTO route at the start of main flow tour since it's used
by it. Also fix a small bug when the form view is open from a
create edit where the route are hidden.
closesodoo/odoo#55790
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
commit 51425344bb96c3b2fee8c813549bbd4561172790 introduced
a duplicated set_values so the original one is ingored and
the transit location is never acivated
closesodoo/odoo#55419
X-original-commit: 6dba1f24627928cfecd84e364e24663c7e9d7806
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Improve onboarding by removing the replenish on order route.
Companies that do MTO process could unarchive the route in
order to have a basic configuration.
closesodoo/odoo#55147
Task: 2245882
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Add two compute fields for picking model:
- `products_availability` will indicate the products' availability for
delivery (outgoing picking).
- `products_availability_state` is used to decorate the field in the
list view.
task-2058495
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>
After the odoo/odoo#52949 , the registering of tracked component,
in case of subcontracting, was broken. Fix and try to mimic
the same flow than before. The produce wizard has been replaced
by a clean MO form to register component and use backorder mechanisme
of MO to manage tracked finished product + tracked component.
task-2278147
closesodoo/odoo#54994
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this commit, This validation message was not displayed properly. (See https://nimb.ws/zYBLvh )
Now we are displaying validation error Properly.
closesodoo/odoo#51209
Signed-off-by: Simon Lejeune (sle) <sle@openerp.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>
- Activate the packaging
- Show detailed operation of receipts
- Create a receipt for some products
- Validate
- Unlock the picking
- Set a Destination Package, save
The product doesn't appear in the package.
The trigger was incorrectly removed in 8750d6a97954e59259d and
507101434f9221f2cfa6d.
opw-2299529
closesodoo/odoo#54908
X-original-commit: aeb969a0f0b1786a2303906352931229b2f63bb9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Avoid concatenation of translated strings & raw values and/or other
translated values, and use the new _ API (by providing the formatting
values to ensure the fallback on the english terms in case of wrong
translation).
By including the expected values inside the string to translate, we
ensure that the formatted values are included at the right place in the
resulting translated text.
This also provides more information on the string to translate to
the translators, s.t. the chosen terms for the translations can be more
adapted to the translation context.
closesodoo/odoo#54635
Related: odoo/enterprise#11925
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
_set_quantity_done_prepare_vals is call to (re)create move line
during some onchange/compute. But it never removed empty line.
Then remove empty line (when no reserved quantity and no done quantity)
task-2278147
X-original-commit: a1ab74d6cd75cee64fcd432d387180299fd64c72
At bee938e (following task-id 2042303), the label of the action was
changed globaly.
The action is however shared with multiple menus like Inventory Report.
The Update Quantity label only makes sense when coming from the
product where the quantity will be updated.
Closesodoo/odoo#50523
1. Create a new location of type internal in WH/Test
2. Create a new product P with availability of 100.0 in WH/Stock
3. Create a new transfer from WH/Stock to WH/Test with 50.0 units of P,
Put in Pack and Validate
4. Create a new transfer from WH/Test to WH/Stock/Shelf 1 using the
previous package, Validate and Unpack
5. Repeat steps from 3 and 4
6. Create a new transfer from WH/Stock/Shelf 1 to Customer with 100.0 units of P
7. Review stock quant from the location WH/Stock/Shelf 1
2 quants of the same product in the location WH/Stock/Shelf 1: one
negative with -50.0 and another positive with 50.0
The step 4 creates 2 quants of 50.0 units, which are reserved at step 6.
However, when validating the transfer 100.0 units are taken from one of
the quants.
To prevent this situation, we run the quant vacuum process after
unpacking. This will merge the 2 quants of 50.0 and prevent any future
negative quant creation. We also clean zero quants, although this is not
mandatory to fix our use case.
Closes#53535
opw-2283707
closesodoo/odoo#54431
X-original-commit: f7168311f4333f7fc684e00e1c1c284981718335
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a product P, tracked by lot
- Add some stock with a lot
- Create an outgoing picking
- Set 10 units of P
- Set 2 done, Put in Pack
- Unreserve
An error occurs: 'It is not possible to unreserve more products of P
than you have in stock.'
It happens because the `lot_id` is removed from the copied
`stock.move.line`.
Commit eac8c06e2233d93e0b1a520e makes sense for incoming pickings, but
not for internal or outgoing transfers.
opw-2288208
closesodoo/odoo#54355
X-original-commit: ed738fb56ffe84f3af08b84e429db916a5e560b6
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Issue
- Install English and French languages
- Create a customer contact and assign french as his language
- Create a product with correct names in both languages.
For example 'French product name' and 'English product name' for easy reference.
- Create an inventory transfer with the french customer as contact
- Add the product that you created
- Print > Delivery Slip
The report will show in the lines:
"""
French product name
English product name
"""
Cause
Getting product description without checking partner language.
Solution
If partner is set, get product description with partner language in context.
opw-2280490
closesodoo/odoo#54061
X-original-commit: cebe2cf57e68e2d1d54cd442aff6ba7d9554d043
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
This commit extends the delivery slip so that products added as a kit
component to a stock.picking are grouped together by kit (or non-kit)
when at least 1 kit exists. Kit grouping occurs for products from a kit
without a package assigned. Non-kit section appears only when no
packages are assigned.
Implementation notes:
- Sub-kits (i.e. kits within kits) of kits are purposely not included
- Duplicate product names with different BOMs will be merged into one
since there is no straightforward way to distinguish them within
current db structure
- There are some cases where this doesn't work as expected and may lead
to components being grouped together under the same kit even if they
are from different kits (e.g. kit1 has bolts and so does kit2 => on
slip bolts will only show under kit1 section). Two cases where this
happens is when kits are added before 'Operation Type' is specified
and 'Operation Type = Manufacturing'
This completes subsection 1 of overall Improve delivery slip task.
Task: 2039720
Rémy Voet (ryv)