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>
Currently on stock moves, product_uom_qty indicates the demand qty
before the move is done and it indicates the acutual done qty when
the move is done.
As a result, when validate a stock move with qty_done !=
product_uom_qty, a new move is always created for the difference.
And the product_uom_qty of the original move will be changed to match
qty_done.
In this commit, we change to that product_uom_qty will always indicate
the demand qty, and qty_done will always indicate actually done
quantity.
To do that, when underconsumption, we won't split the move when no
backorder. and when overconsumption, we will always merge the extra move
back to the original move.
Task-2695732
Part-of: odoo/odoo#130342
These changes are made as a result of simplifying attrs and 'states' in
views. However, they should have remained in a separate commit. When
applying the script making the xml changes (used later for the migration
script), the script checked the definition of the python fields in order
to convert the information into a python expression. Therefore, this
commit is not applied when the script is applied to xml changes.
During this attribute deletion pre-existing errors were found. Part of
the code was using the boolean values of 'states' and another part of
the code was not. The behavior could therefore be different (in cases
where readonly on the field had the same value as the ballan in
'states').
Following the deletion of 'states' and without the application of the
view migration, the js tests (tower) were no longer functional. Tests
using the Form view suffered the same effect. There are few tests that
had to be adapted, including two tests in business accounting (updated
by the accounting team). A test for column_invisible did not work. Test
checking if the test system triggers an error if we try to write on an
invisible field. It turns out that Form was testing on the value of
invisible but not taking into account if the column was invisible. The
test system fix is applied separately because there were a lot of tests
that were incorrect.
Part-of: odoo/odoo#104741
When processing a batch without backorder, if a picking is not fully
done, it will be removed from the batch
To reproduce the issue:
1. Create two delivery pickings P1 et P2 with demands = 5
2. Have the quantity in the stock
3. Add both to a batch and confirm it
4. Set the done quantity on P1
5. On P2, set a done quantity to 4
6. Process the batch without backorder
Error: Both pickings are done, and so does the batch, but P2 is not
linked to that batch anymore
When processing the batch, we will call `button_validate` on the
pickings recordset
https://github.com/odoo/odoo/blob/213b74be16cecc50e6e99c00f47786a9cbf327a8/addons/stock_picking_batch/models/stock_picking_batch.py#L252-L258
Later on, there is an override of `StockPicking._action_done` in the
batch module. In this override, once we have called `super`, we then
ensure that all pickings of the batch are done, else we detach some
of them:
https://github.com/odoo/odoo/blob/213b74be16cecc50e6e99c00f47786a9cbf327a8/addons/stock_picking_batch/models/stock_picking_batch.py#L252-L258
But here is the issue: as mentionned above, we first call
`button_validate` on pickings recordset. In this method, we will
call `StockPicking._action_done` two times:
https://github.com/odoo/odoo/blob/ca168f7fbcbb8a300a8fa0b46f79a6c116b5aa93/addons/stock/models/stock_picking.py#L1088-L1089
The first time, for the pickings without the backorder option (P2 in
the above use case), and the second time, for the pickings with the
backorder option (P1 in the above use case). As a result, during the
first call, we reach the override in batch module, and of course, P1 is
not yet processed (it will be done during the second call of
`_action_done`). Therefore, we think there is an inconsistency, and we
detach P2.
OPW-3346255
closesodoo/odoo#132037
X-original-commit: c2817285adf9dd44ad7155963f08d324995ba072
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@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>
This commit makes hotkey uses more coherent throughout the entire
codebase by setting alt+q as main shortcurt for confirm and default
actions and alt+x for cancel actions.
task-3370463
closesodoo/odoo#127469
Related: odoo/enterprise#43694
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@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>
Odoo Translation Bot