By only auto-batching pickings that are ready, it allows, if you reserve
X days in advance, to make batches for those periods, almost like batch
on the scheduled date.
Part of task-3218314
Part-of: odoo/odoo#119381
PR https://github.com/odoo/odoo/pull/106414 made it so the
`product.label.layout` expecting `stock.move` ids rather than
`stock.move.line` ids. Unfortunately it missed updating this for the
batch picking case => when printing the labels for a batch picking,
only 1 label was printed per product rather than the qty done.
Note that this issue does not occur when the batch is Done + has
lots/SNs assigned in it
closesodoo/odoo#118995
X-original-commit: a5af45a8e3ff8860655351dd76a11f1dbb6d8a70
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
When using message_post, the body format must be explicitly specified.
If html is expected, a Markup object should be used.
If text is given, the content will be escaped.
Before this PR:
message_post was unaware if the content of a message was HTML or
text. This lead to multiple situation where the content was
incorrectly considered as HTML and led to display errors.
In
self.message_post(body="Hello %s!" % self.name)
if the name contained HTML, it would be evaluated.
In
self.message_post(body="Contact Raoul <raoul@caramail.be>")
the email would not be displayed as considered as unknown HTML and
discarded by the sanitizer
Now each call must explict the type of content.
Use the escape() helper to properly combine Markup and translations.
It would also be acceptable to use Markup() to wrap a static
translation but escape is better as one can not guarantee the content
of a translation.
closesodoo/odoo#111850
Related: odoo/documentation#3612
Related: odoo/enterprise#36728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Commit 324298967cb6 fix the call to _find_auto_batch() by calling
_action_confirm() of the picking _after_ the assignation.
This implies to confirming 2 times the pickings. Which is an issue in
case an automatic orderpoint is searched and triggered. to fullfill the
need in the source location.
This commit change the call to action_confirm() to a call to
_find_auto_batch() only
closesodoo/odoo#117100
X-original-commit: eb6da7009a525665d4608243e260a2d07093abcc
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>
The 'To do' picking filter made no sense as it used to check the pickings
that are not assigned or assigned to the user.
The new behavior corrects it by checking if the previously selected pickings
are not in a 'done' or 'cancel' state.
task id : 3087740
closesodoo/odoo#111648
Signed-off-by: Steve Van Essche <svs@odoo.com>
The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Steps to reproduce the bug:
- Enable “multi routes” and “wave transfer in the settings
- Go to warehouse:
- Incoming shipments:
- Select 3 steps
- Create two storable products “P1” and “P2”:
- update their qty
- Create a purchase order:
- Add “P1” and “P2”
- Confirm
- Go to the picking:
- Set qty done only for “P1”
- Validate the picking and create a backorder
- Go to inventory > Operations > Transfers:
- Select the internal transfer from input to quality control
- Action > Add to wave
- A new wave transfer > select the move for “P1”
- Add to wave
Problem:
The operation type is not set on the wave transfer
opw-3112142
closesodoo/odoo#113054
X-original-commit: daed921acacd22f45d95357e131ea11654d73766
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
In `_check_backorder`, changes the condition so it checks if the qty
done is enough compared to the actual reserved quantity (instead of the
demand).
Also, removes an unused bloack of code and makes minor visual changes.
task-3076044
Part-of: odoo/odoo#109511
In the inventory menu, the "Operations" menu has now three sub items:
- Transfers
- Adjustments
- Procurement
All the existing `menuitem` go now under one of these sections.
Also, for the old transfers menu itme, this commit replaces it by three
other menu items: "Receipts", "Deliveries" and "Internal Transfers".
Each of them will display only the transfers with the matching picking's
type (depending of the picking type's code).
When a picking is created from there, its picking type will be set by
default according to it and the field will be filtered by its code.
When `mrp` is installed, adds a menu item for the manufacturing
operations in "Transfers" submenu too.
task-3076044
Part-of: odoo/odoo#109511
Steps to reproduce the bug:
- Enable “batch transfers” in the inventory settings
- Create a new warehouse “WH2”:
- Enable “Resupply From” option
- Enable “3steps”
- Go to the operation type “internal transfers” of WH2:
- Enable “Automatic Batches”
- “Destination Location”
- Create two storable product “P1” and “P2”:
- Route: warehouse # 2: Supply Product from YourCompany
- update the Qty to 10 in wh/stock
- Create a replenishment for “P1” and “p2”:
- Location: WH2/stock
- Preferred route: warehouse # 2: Supply Product from YourCompany
- Procurement Group: select two different procurement
- min qty: 1
Problem:
Two internal pickings are created for “P1” and two others for “P2”,
because two different procurement:
- from “input” to “quality control”
- from “quality control” to “wh/stock2”
But as the pickings have the same location destination, two batches
are supposed to be created to group the pickings.
The `_find_auto_batch` function is triggered when the picking is
confirmed:
https://github.com/odoo/odoo/blob/16.0/addons/stock_picking_batch/models/stock_picking.py#L120
but since the pickings are not confirmed, the function is not called:
opw-3076077
closesodoo/odoo#111716
X-original-commit: 324298967cb63d7de1144c8aee2039119443e60c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Enable “package” option in the settings
- Create a storable product “P1”
- update the stock to 100
- Create a picking:
- product : P1
- Qty: 1
- operation type: delivery
- go to additional info > add a carrier
- Mark as todo
- update the qty done to 1
- Create a second picking with the same steps
- Create a batch picking:
- Add the picking 1 and 2
- Confirm
- Go to “Detailed operation” tab
- Click on “Put in pack”
- add a “Delivery packaging”
- Save
- Click a second time on “Put in pack”
- Select the same “Delivery packaging”
- Save
Problem:
Traceback is triggered: “tuple index out of range”
When the “Put in pack” button is clicked, the “action_put_in_pack”
function is called, the move_line_ids which has no package or with
a 0 quantity done are filtered, in this case the 2nd move_line with
the product “P2” will be used, but the `_pre_put_in_pack_hook` function
is not called with its picking:
https://github.com/odoo/odoo/blob/14.0/addons/stock_picking_batch/models/stock_picking_batch.py#L229
But rather with the first picking, it will have no move_line because the
first move_line already has a quantity done at 1 and a package.
So we try to get a record in an empty array:
https://github.com/odoo/odoo/blob/14.0/addons/stock/models/stock_picking.py#L1312
opw-3067921
closesodoo/odoo#106943
X-original-commit: 1b6208a2db00ed387bcd0833787fa05416a426ba
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Following odoo/odoo#103743
Changes the xpath adding the `batch_id` in the picking list view from
before `company_id` to after `picking_type_id` because the linked commit
added an invisible `company_id` at the start of the list, so the
`batch_id` was wrongly placed.
closesodoo/odoo#104981
X-original-commit: d3f6bd6f12048233b57566cdedf6f2b22a45dd93
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
Since odoo/odoo#95729
nodes with a `groups=` are completely removed from the views when
the user is not part of the group, instead of being made invisible.
In that PR, views have been adapted to add back fields, with invisible="1",
when they were required, for instance when they were used in a domain
of another field which was still there despite the user is not part
of the given group.
As `tree` views having `multi_edit="1"` where not considered
as editable views, the domain of fields in these views were not
validated:
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1460
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1321-L1322
while they are well required for the web client,
in `multi_edit="1"` this is possible to edit relational/many2one field,
and therefore it will do `name_search` calls using the domain of the
field, and therefore the fields used in these domains must always
be present in the views. Without it, a crash in the web client occurs
when attempting to edit the relational/many2one field.
This revision targets to consider the `multi_edit="1"` tree views
as editable, to make the field domains validated as they should be.
Hence, views are adapted to add back fields with `invisible="1"`
when they are required in domains of other fields.
Part-of: odoo/odoo#103790
If a stock picking wave is created from move lines. It may happen no
picking type is set on the wave. If an entire stock move or an entire
picking represented by the move lines 'to wave'. a picking type is
correctly set.
This commit ensure a picking type is set directly from the move lines
closesodoo/odoo#103348
X-original-commit: 86a1f2219904a19166155555da873b1772efa620
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Hides the empty label the same way as the group-by field if it doesn't
need to be shown (no default_location_dest_id/default_location_src_id).
Part of task-2985735
closesodoo/odoo#102759
X-original-commit: 6030147e12b628e8759700058b8ac3c3889007a8
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
When selecting the "Add to batch" wizard, if a user selected "Add to an
existing batch transfer", the only batches appearing there would be only
draft batches, while it could be added to in_progress batches as well.
It also displayed waves transfers with the batches, so it now only shows
batches.
Also restricted the creation of a batch in the related field since there
is an explicit option to create a new batch transfer.
Somewhat the same for the "Add to wave" wizard as it would display
cancelled waves as well.
Part of task-2985735
closesodoo/odoo#102715
X-original-commit: a8db2c5fe4b2ea1f28c6ea788ac1976678da11aa
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
When a backorder was created and the auto_batch was activated for this
picking_type, no batch was assigned to the created backorder, even if it
matched the auto-batch criterias.
Now when a picking is done, we check if backorders were created. If they
are eligible for auto-batchs (given their picking_type, etc.), they also
get the auto_batch done for them.
We can't simply use the previous picking's batch, because if this batch
is now done, then introducing a non-done picking into the batch would
raise an inconsistency between the pickings' states and raise an error.
Removes the old override of backorder confirmation as now batch
dissociation is done in the picking's 'action_done()' override.
Allows the validation of a batch that has pickings 'waiting for another
operation', as they now will get removed from the batch in the process,
no longer blocking the batch's validation.
Finally, makes that pickings that had no quantities done when validating
a batch aren't cancelled when selecting 'No backorder' in the
confirmation wizard, but are instead removed from the batch.
Task-2971346
X-original-commit: 1720840b7bd9b3e3e90f7cf860f60f1d0746ce63
Part-of: odoo/odoo#102382
the choose line widget is never used and can be safely removed.
closesodoo/odoo#101484
X-original-commit: 96462cec054d05955839a4a24d1c6aa9a3c7d7e2
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Currently cannot see assigned user working on picking/batch in kanban view.
Added user_id in picking kanban view, and related user_id
from batch
TaskId: 2871679
ENT PR: odoo/enterprise#28886closesodoo/odoo#101026
X-original-commit: 943e5b9761b43257ec968c12f15723c618c3b5ad
Related: odoo/enterprise#31740
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Ahmed Khalaf <ahkh@odoo.com>
Note this includes the view shown when clicking on:
- "History" button in inventory adjustments
- "Product Moves" button in scrap/product forms
- "Reporting" > "Moves History"
At time of this commit being written. Other move line views not changed
since they are specific to inputting data rather than readonly data.
Minor UX updates to stock move lines report:
- rename "Units of Measure" column to "Unit"
- add color to quantity field (green = incoming qty into stock, red =
outgoing, black = all others [i.e. internal transfers/external
locations only, etc]
- search filter order updated + src/dest location filters replaced with
generic filter that checks if either meets condition
- add src/dest package to list view
- add status, lot, and from/to dest to kanban view and replace picking
with reference so inventory adjustments are visible as well
- order by date desc so most recent ones are first
- always display location src/dest to help understanding of moves
Specific to "History" button in Inventory Adjustments / Reporting >
Locations (i.e. inventory report), moved product_id from domain to
default_search for more user analysis flexibility/ease.
"product moves" part of b2b task: 2882539
Part-of: odoo/odoo#97109
- reorder/rename/remove menu contents for "Inventory" and "Reporting",
including:
- removed "Forecasted Inventory" menuitem since this view is no longer
considered useful (code for view to be removed in separate commit)
- removed "Stock Moves" (moves report) menuitem
- renamed "Product Move" (move lines report) menuitem => "Moves
History", this will also be reflected in any "History" buttons that
open this view from other views.
- made "Inventory Report" menuitem visible only when applicable (i.e.
multi-location or consignment is active/debug mpde)
- made "Run Scheduler" menuitem only available in debug mode (
main_flow_tour updated to skip scheduler click since general flow is
expected to still the same/work)
Goal of renaming/ordering of menuitems is to clean them up and make them
more intuitive for users.
- "Run Scheduler" in mrp menus has also been made debug only viewable as
well to mirror the inventory change.
"menu" part of b2b task: 2882539
ENT PR: odoo/enterprise#29974
Part-of: odoo/odoo#97109
Purpose
=======
Confirm batch when `Draft` checkbox is unchecked.
So in this commit, we have added one `Draft` checkbox in the batch wizard.
While creating a new batch, if this `Draft` checkbox is checked then batch will be
create in draft state and if it's not then the batch will be create in confirm state.
TaskID - 2925593
closesodoo/odoo#97084
Signed-off-by: Tiffany Chang <tic@odoo.com>
This revision is to make uniform the behavior of the `groups` attribute
on the Python model fields
and on the node in the view architecture.
In both cases, remove the node from the view completely.
Before this revision,
in a back-end view:
- In the Python model, if a field has the `groups` attribute set
and the user is not part of
the groups, the field is removed, completely, from the view.
- In the view architecture, if a node has the `groups` attribute set
and the user is not part of
the groups, the node is made invisible (not completely removed, just
made invisible).
in a front-end view:
- if a node has a "groups" or "t-groups" set and the user
is not part of the groups, the node is removed from the view.
So it's 2/3 cases removing nodes restricted to a group.
and 1/3 case making invisible nodes restricted to a group.
It's simpler to have a uniform behavior for the 3 cases,
simpler to understandard for developers.
In addition, this will help for the goal to cache back-end views.
It makes possible to convert views using the `groups_id` field
by moving the content of these views directly
in the view to which they add content which is suppose to be completely
removed when the user has not the according group.
By getting rid of the `groups_id` many2many field on `ir.ui.view`,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the `groups_id` groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
closesodoo/odoo#95729
Related: odoo/enterprise#29592
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
When adding list of transfers to batch from transfer tree view,
if transfers belong to two or more batches an error traceback pops.
To reproduce:
1-Create Transfer 1, go to Transfer list view and add it to batch under Action, choose
add to a new batch transfer and confirm.
2-Create Transfer 2 and do the same.
3-Now that we have two transfer belonging to two different batches,
Under Inventory->Operations->Transfers, select the two transfers
in the tree view and choose add to batch under Action, choose add to new batch
and confirm, error popsup
Bug originated from: #89815
Discovered while working on TaskId:2871679
closesodoo/odoo#97998
X-original-commit: 82580b0ba9dbbfb244ede233a251b059e2c233ba
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Ahmed Khalaf <ahkh@odoo.com>
This commit removes a needless `ensure_one` in batch `action_cancel`
X-original-commit: cf6013fff67441f67800df56349877c820873110
Part-of: odoo/odoo#97998
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
As done with the "done" state, if a single picking in a batch is
cancelled while the other pickings aren't, this picking is removed from
the batch, as it would create inconsistencies between the states of the
pickings in a single batch.
closesodoo/odoo#90449
X-original-commit: 1f2813e59970cd2eb078b514cd7d563837f175a1
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Steps to reproduce the bug:
- Create a batch transfer with several pickings
- Confirm it
- Delete all the pickings > save
Problem:
The batch does not cancel as it should’ve been
A batch without transfers cannot be confirmed, so it makes no sense to leave a confirmed batch without transfers
opw-2792471
closesodoo/odoo#90104
X-original-commit: dcbf08edbb3a1ec49e84f0828b8f49ac4f836c25
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Current behavior:
All batch transfers are shown in the tree view. But only the one for the allowed companies should be in the list
Steps to reproduce:
- Be in a multicompany environnement
- Activate batch picking
- Go in Inventory/Batch transfers
opw-2752617
closesodoo/odoo#86531
X-original-commit: 8415b48cae06124911f08fe6c01b029ed80e6286
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Steps to reproduce the bug:
- Create a batch transfer with moves from the same warehouse to several locations, e.g:
- Product A from `WH/stock` → `customer/stock1`
- Product B from `WH/stock` → `customer/stock2`
- Try to print the batch transfers
Problem:
Traceback is triggered because we do a loop only on location_from
Solution:
- We need to loop over location_from and location destination
- Remove useless use of mapped
opw-2768518
closesodoo/odoo#86082
X-original-commit: 6721d1dfe53fb8d301188f2fb4c21baa70c27b92
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
If a picking is in a batch, the point is to process it as a whole. Yet,
it is possible to validate a single picking (putting it in a 'done'
state), inside of an 'in_progress' batch. This raises inconsistencies
between the state of the batch as a whole and the state of some of it
pickings.
Therefore, when a single batched picking is validated in a batch that
still contains other non-done pickings, the picking is removed from the
batch.
closesodoo/odoo#85324
X-original-commit: e9602d6b28331f68a83b5ce8a06a2ffc8ac3453d
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Usecase to reproduce:
- Product A 0 unit in stock
- Product B 10 unit in stock
- Create planned delivery with product A and B
- Do a wave transfer and selected reserved `stock.move.line` from
product B
Current behavior:
The whole picking is move into the batch
Desired behavior:
The picking is splitted and only the move for product B is in a new
batch
It happens because the add_to_wave function check if all the picking
`stock.move.line` are in the `stock.move.line` to batch. If it's the
case, it moves the picking in the new batch. However in our case,
some `stock.move` are not reserve and should not be move in the new
batch. Also check if all the quantity is reserve on the `stock.move`
if it's not the case split the move to only put the reserve quantity
in the wave picking
closesodoo/odoo#85038
X-original-commit: afe2a3a7f913459d88ef197e63bc897fda5f90f8
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Usecase to reproduce:
- Create an immediate transfer and enable detailed opeations on the
picking type
- Create 2 `stock.move.line` with qty_done = 5
- Add the picking to a new wave and select only one of the sml
Traceback
It happens because the move split is base on the reserved quantity.
However in the case of an immediate transfer, the reserved quantity is
zero and the split fail
X-original-commit: 709372b0160a93cb9c30d391c4b3fc6c07ea2f9a
Part-of: odoo/odoo#85038
clesgow