Previous fix: odoo/odoo#139013 added in the ability to handle a use case
specific avoided due to its complexity and it being an edge case. I.e.
the ability to do a Put in Pack in a batch picking where there is a
shipping connector involved (i.e. when the `choose_delivery_package`
wizard is opened).
Because the ability to handle this situation is now added to stable, we
have to sort of support it now and handle it not breaking other flows.
Here are the flows that need to be handled (and were broken by the
previous PR): [In all cases, "Packages" setting needs to be activated
and each picking needs at least 1 move of a consumable/storable product]
Flow 1: batch picking + put in pack for single picking
- Create 2 pickings of any operation type
- Create a new batch picking with these 2 pickings
- Open 1 of those pickings directly (i.e. not in the batch)
- Click on "Put in Pack"
Expected result:
Only the move from the open picking is put into a package
Result before this commit:
Both pickings have their moves put into the same package
Additional notes: Because this is not an obvious bug, users may already
had this bug occur in their DBs without realizing it
===
Flow 2: batch picking (or multi-record calling of `action_put_in_pack`)
[different in v17 onwards due to removal of immediate_transfer boolean]
- Create 2 pickings (of different picking types)
- Select both pickings (through direct call in shell or rpc) and call
`action_put_in_pack`
Expected result:
Moves are blocked from being put into same package since this situation
doesn't make sense (i.e. the products are moved to different locations
but the package can only be in 1 location)
Result before this commit:
The moves will all be put into the same package
Additional notes:
In theory batch picking creation has checks to avoid batches where
there are pickings with more than 1 picking type or have different
`show_reserved` values, but because `_package_move_lines` is a method
that can be called in different use cases (including multi-record
pickings) via customizations/future code changes, we add in checks to
prevent put in pack from finishing in those cases to avoid unexpected
behavior/stack traces. I.e. remember to respect existing
`self.ensure_one` checks since they're probably there for a reason.
===
Flow 3: batch picking w/pickings w/more than 1 delivery carriers (where
none = a different carrier than having 1)
- Create 2 delivery pickings with different `carrier_id` values (i.e.
different shipping methods assigned to them)
- Add both pickings to a batch
- Click "Put in Pack" in the batch picking
Expected result:
None, we should not handle this case because if the products are in the
same package then the same package info will be sent to both carriers
and the user will be double charged for every move (or
charged(/potentially create the wrong shipping documents) when it
shouldn't be in case of no carrier for one of the pickings)
Result before this commit:
All moves are put in the same package and the double
charging/potentially incorrect shipping documents will occur
Additional notes:
This is the use case that was intended to be avoided when flow was
originally decided to not be handled
closesodoo/odoo#157224
X-original-commit: b3498facab77e1eed8969c018e3f966a80e62654
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
For a first iteration, Russian translations were done using DeepL using
1 large .pot file of all the standard modules to translate (e.g. no
localizations, no test modules, etc). Unfortunately for some reason
doing a msgmerge with the existing ru.po files didn't seem to work, so
old "Translators" metadata at top of files were lost (maybe they will be
re-added during next Transifex sync?)
Part-of: odoo/odoo#152285
Steps to reproduce:
- Create a Batch transfer and create two reciept in it
each with a serial tracked product in them
- Confirm the batch transfer
Bug:
in the detailed operation tab of the batch transfer (use existing lots/
create lots) options of the picking type are not respected and lot id is
displayed instead of lot name (many2one instead of char field)
Fix:
keep the same batch transfer as in the pickings that constitute it
opw-3541324
closesodoo/odoo#144582
X-original-commit: 53498d92f1f4de516f4452dd44d3a2c12fd5eb02
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
For multi steps batch pickings, the package is not forwarded
like it is for 'simple' pickings.
closesodoo/odoo#141822
Related: odoo/enterprise#50532
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
- Install DHL delivery and enable batch transfers
- Create 2 SO with adding shipping
- Select the 2 delivery orders and add them to the same batch
- Put the batch in a pack
- Only movelines of the first delivery are put in the pack
Bug:
when delivery is Installed a Delivery Package Type has to be chosen
this will in turn put the active picking mls in pack
the case of batch picking was disregarded
https://github.com/odoo/odoo/pull/55096/files#r469780148
Fix:
implementing a method to get the movelines to pack will allow to simply
make an override in stock_picking_batch instaed of creating a new module
this has also the added benefit of unifiying the behavior accross the
different methods
opw-3357423
closesodoo/odoo#141473
X-original-commit: 2d2bfe7f01379beb695b1c8756be393e17faf7de
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
-> This commit add/change the name of the page corresponding to the string
attribute because To be able to detect a field, Knowledge needs to be able to
read its page name.
For more reference: Task-3501211
Task-3524474
closesodoo/odoo#137428
Related: odoo/enterprise#48315
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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>
Add in feature to allow auto-printing of package label when "Put in
Pack" button is pushed. Note there are 2 choices for package labels and
these choices are hardcoded in as selection options to avoid complexity
of finding all relevant reports (i.e. custom report labels won't be
auto-printable) and exclude the irrelevant reports.
Unfortunately since there are different flows for "Put in Pack", a
separate "_post_put_in_pack_hook" method is needed to manually be called
in some of these cases and additional future use cases will also require
it to be called if this feature is desired in that case.
Additionally clean up _put_in_pack() since it was only called by methods
with ensure_one(), but was semi-designed to handle multiple pickings
(but only returned 1 package in the end, which didn't make sense + had
other errors in it).
Part of task: 3046178 - At package creation (put in pack)
Part-of: odoo/odoo#126791
With the option "Reception Report" enabled, a batch may contains
done and ready pickings, which is inconsistent
To reproduce the issue:
1. In Settings, enable Reception Report
2. Operations Types, edit Receipts:
- Show Reception Report: True
- Automatic Batches: True
- Group by: Contact
3. Create two products P1, P2
4. Confirm a delivery with P1
5. Confirm two receipts, one for each product, both with partner P
- It should create a batch
6. Partially process the receipt with P1, with backorder
- It should open the reception report because of the delivery
7. Open the batch
Error: The first receipt is done but is still part of the batch and
the backorder is not attached to it. Worst: if the user now tries to
confirm a third receipt with the same partner, he will got an error
because of an inconsistency with the batch
[1] is incorrect. The code assumes that if `res` is not `True`, there
was an issue with the picking, so it's better to immediately return
`res` without analyzing the batch. However, sometimes `res` can be a
`dict` even when the picking has been processed correctly. This is the
case here: the receipt is marked as done, but we return an action to
open the reception report.
As a result, in the above case, we directly return the report action,
and we don't analyze the batch consistency (i.e., we don't remove
the done receipt and add the backorder). Then, because of the batch
inconsistency, the user is blocked and can not validate another
receipt.
[1] 0c7122d416a3669d1d42f66bef5b397e8b36a91b
OPW-3346255
closesodoo/odoo#138690
X-original-commit: d92c5a594e57cb2574bcf87ab398919c07c9a738
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
This reverts commit 656d8ace87.
The rational was: "If people don't have inventory, they will need a
backorder anyway and it's logical to not display the popup even
if the picking type has 'ask' for create backorder".
Also for the barcode application in OE we only show the reserved lines and
you could have the message if the picking was not fully reserve. Even if
you completed all the lines. So we could have a single flow for backend
and frontend.
But it's difficult for poeple to understand that the backorder is
base on the reservation and not on the initial demand. So we do a
step back. On top of it, people usualy won't mix flow. So they
could totaly use the "always create a BO" option on picking type
when they use the barcode and "ask" when they use the backend.
closesodoo/odoo#136725
X-original-commit: ed291c4d47783c5912ffb40db7893c321ccdb1e2
Related: odoo/enterprise#47959
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
List of transfers shown in the Batch Transfer form was using a simplified
view, without proper coloring etc. That list was removed, so now the
default list of transfers is used and the view is more consistent.
The change is applied both in the Batch Transfers form (in the "Transfers" tab),
and in the popup visible after clicking "Add a line" button.
Task: 3290154
Related: odoo/upgrade#5138
Part-of: odoo/odoo#122511
This commit replaces the opening of the stock moves detailed operation
wizard by the one2Many record preview. This means creating a move in a
picking is still done via a new line but the edition is done via the
`fa-list` button that open the record in the web client. The goal is to
reduce the RPCs call as much as possible. The stock move lines data are
stored in the stock move record until the picking save.
Additionally, this commit change a bit the immediate transfers flows.
The stock move show only initial demand (`product_uom_qty`) but the
column wording is still "Done". In the detailed operation view, the
stock move line `qty_done` is displayed as "Reserved".
At picking validation, the user is expected to enter the same quantity
in `product_uom_qty` and `quantity_done`. If `product_uom_qty` is equals
to 0, the done quantity is used as actual transfer quantity. If
`product_uom_qty` is different than 0 but small than the done quantity,
an error is raised.
Task: 3256447
Part-of: odoo/odoo#124409
Minor cleanup after odoo/odoo#104741 thanks to edge-cases and the fun
complexity of logistics code. Fixes include:
- removing some readonly=False that were added on computed/stored fields
that already have an inverse func or were already not readonly (i.e.
redundant => cleanup)
- fixed visibility of qty to prod in subcontractor portal view of a MO
(i.e. yay they know how much they're supposed to make again)
- remove unused imports
- adding back in readonly functionality of default dest of repair
operation type (and removing the now useless field override that used
to add in the readonly functionality)
- adding back in the `_set_product_qty` inverse function since it was
probably removed by mistake (and is still important to have)
unrelated to viewpocolypse change, also fixed:
- mobile view of PO was for some reason allowing products to be changed
in already confirmed/done POs, which could lead to some inconsistent
data => made this consistent with existing desktop view behavior
closesodoo/odoo#133502
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Odoo Translation Bot