Before this commit
===================
In MO if a line is deleted or line has its to consume quantity reduced so in
done state transfers return is creating.
After this commit
===================
Stopped creating the return on done state transfer when quantity is reduced or
a line is deleted.
closesodoo/odoo#133696
Task: 3283010
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Fixes 2 use cases:
- barcode redirect after picking is validated (should return to menu
instead of refreshing the validated picking). Issue was due to missing
renaming of "on_close" to "onClose" after refactor occured
- ensure the auto-print action during MO validation always has a context
because the "Shop Floor/MES" expects any returned actions from
validation to always have a context to add the extra context parameter
of "skip_redirection" to it
closesodoo/odoo#140352
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.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 auto-print reception (allocation) report when the
MO is done. Note that only MOs with an allocation will be printed
otherwise the form will only have the MO name/barcode and nothing
else in it (i.e. not very useful).
Part of task: 3046178 - general auto-print goal
closesodoo/odoo#126791
Related: odoo/enterprise#43362
Related: odoo/upgrade#5298
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Add in feature to allow auto-printing of lot/sn labels when the
`action_generate_serial` button is pushed.
Part of task: 3046178 - MRP behavior auto-printing
ENT PR: odoo/enterprise#43362
Part-of: odoo/odoo#126791
Add in feature to allow auto-printing of lot/sn labels when MO is done.
Note that this includes byproducts and does not consider the qtys done
since that is already printed as part of the product labels (which
auto-fills in their lot/SNs as their barcodes)
Part of task: 3046178 - MRP behavior auto-printing
Part-of: odoo/odoo#126791
Add in feature to allow auto-printing of reception report labels
when MO is done when there are lines assigned in the reception
report (i.e. any MTO linkages/move_dest_ids).
Part of task: 3046178 - MRP behavior auto-printing
Part-of: odoo/odoo#126791
Add in feature to allow auto-printing of Production Order report at MO
completion. Note that existing backorder view actions had to be adjusted
because lack of `views` param did not work with specialized client
action to chain actions.
Part of task: 3046178 - MRP behavior auto-printing
Part-of: odoo/odoo#126791
Steps to reproduce:
- toggle setting `mrp.group_mrp_reception_report = True`
- create a new 'mrp_operation' operation type and activate
`auto_show_reception_report` for this operation type
- create a delivery of a product (qty > 1)
- create 2 MOs for the product to deliver, one with the new operation
type and one with the built in operation type
- try to "Mark as Done" both MOs (from the list view)
Expected result:
MOs are marked as done, only 1 of the MOs shows up in the allocation
report for the delivery
Actual result:
Singleton access issue
Noticed during task: 3046178
Part-of: odoo/odoo#126791
Fixes a large number of cases where strings are translated then
formatted, instead of letting `_()` do the formatting internally,
which allows it to recover from incorrect translations (missing,
broken, or extra placeholders).
Also
- removes translation markers entirely when there's nothing to
translate e.g. `_("%s - %s")` is not useful
- fixes a few messes which lead to only partial translatability
(DRY is generally a bad idea when translations are involved, even
more so when you don't make the variable part translatable)
- fixes a few nearby issues noticed at the same time
- replaces a few `"%s"` by `%r`, which should automatically quote
strings relatively appropriately
- fixes translated strings which use `\` to escape a newline (in order
to fill-paragraph): `\` escapes only the newline, if the
continuation string is indented this results in a bunch of spaces
ending in the string to translate, which is pretty garbage for the
translator, using implicit concatenation works much better
Note: some of the updates revert f-string parameters to %, because
babel (2.9) apparently has trouble with f-strings and blows up trying
to extract them.
Not in scope:
Helping translators fix translatable strings e.g. any translation
string with more than one placeholder probably should use keyword
placeholders
- Provides more context / data to the translator to make sense of the
sentence.
- Allows reordering the translated terms, which can be necessary
depending on the sentence and language.
closesodoo/odoo#139314
Related: odoo/enterprise#49311
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When marking an MO as done in the shop floor, the pre_mark_done method
is used to determine if there are any issues before putting the MO in
the 5 second validation queue.
However, there were two cases that were not yet caught here:
1. Pending quality checks on a workorder
2. Duplicate serial number on the final product
This commit adresses both of these cases.
closesodoo/odoo#137535
Task: 3456827 (nr 28)
Related: odoo/enterprise#48379
Signed-off-by: Steve Van Essche <svs@odoo.com>
When changing the duration on a time-tracking entry on a workorder, set
the end time to now and calculate the start time by detracting the
duration, instead of the other way around.
Task: 3456827 (nr 35)
Part-of: odoo/odoo#137535
Before this commit
=================
While updating the Bill of Materials (BOM), the work center and operation name
remained unchanged in the manufacturing order.
When Archiving/Unarchiving the operation doesn't show the "Update BoM" button
in the appropriate MO.
Steps to Produce
================
- Create a BOM1 with operations
- Create a MO with BOM1 and confirm MO
- Goto BOM and change the workcenter and operation name
- In MO Click on the 'update BoM' button
- Now you see the operation name and workcenter are not updated in MO
After this commit
=================
With this commit the work center and operation name get updated with the update
BOM click. For Archiving/Unarchiving the operation results to the display of
the "Update BoM" button in the appropriate MO. Directly editing an
operation will also cause the "Update BoM" button to appear
task-3461985
closesodoo/odoo#138256
X-original-commit: c343ebf0a28f6404f7ad6fc892c4a42edd2bbbe0
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Maintain the playful tone whilst avoiding nonsensical phrasing.
I will not take comment at this time, thank you.
Task-🤔🙃😬💅😐🤓closesodoo/odoo#138302
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Before this commit error messages in odoo are boring and
not much attractive to user. Those were like odoo is preventing
them from doing something user want to do.
In this commit, we have modified the message to be a more friendly
and humorous tone, making it less tedious and more enjoyable. It
aims to enhance the user experience and ensure that interactions
with any application are both pleasant and informative. As a result,
the messages have been clear, short, easy to understand and informative.
task-3356114
Part-of: odoo/odoo#124820
Co-authored-by: Kamlesh Pathekar <kpt@odoo.com>
The traceback arises when the user removes the 'product' from 'stock.move'
and try to add the product in 'mrp.production'.
To reproduce this issue:
1) Install 'MRP'
2) Create a new record for 'Manufacturing Order'
3) First add a line in 'Components'
4) Remove the 'product_id' from component
5) Now try to add 'Product' in mrp
Error:-"AssertionError: precision_rounding must be positive, got 0.0"
on the '_compute_state' method when the state is in 'draft' and
the user added a line in 'move_raw_ids'.
In this case, precision_rounding is getting value from
'product_uom.rounding' or 'product_id.uom_id.rounding' through 'move_raw_ids'.
See:- https://github.com/odoo/odoo/blob/10e0ac377cc235d81819eaa2a4ec2b6a60fffd70/addons/mrp/models/mrp_production.py#L478-#L479
When the user removed 'product_id' from 'move_raw_ids', 'precision_rounding'
will be '0.00'. Which leads to the above traceback.
Applying this commit will resolve the issue by giving a default value of '0.01',
when the 'precision_rounding' value is '0.00'.
sentry-4220927307
closesodoo/odoo#137904
X-original-commit: 5c238bbb18c682ff2d25f740aad604feb7bb5bbc
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: Altaf Shaik (alsh) <alsh@odoo.com>
Since commit[1] Serial number sequence rule takes priority over already
existing Serial numbers
Bug:
when disabling default Serial number sequence rule a validation error
is thrown since lot name is now empty
Fix:
fall back on the previous behaviour (get next SerialNumber) if sequence
is not set
(also added a clearer user error if neither is set)
note also updated the .pot file
opw-3514794
[1]:https://github.com/odoo/odoo/pull/134187closesodoo/odoo#137756
X-original-commit: 68d670a27be7baaaf53b0cf491234f8e0453d7f2
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to reproduce:
- Create a component C (automated/FIFO)
- Create and confirm two PO for C
qty: 1, price: 10
qty: 1, price: 20
- Make an MO with C as a component
- Unbuild that MO
Bug:
The valuation of the new component C is wrong, the new move in is valued
at the current product cost instead of its original value.
Fix:
create moves as a return to get the correct value
opw-3379457
closesodoo/odoo#137353
X-original-commit: d42238cc75fe6621c1eb893395856870c8bfbafb
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to reproduce:
As Admin:
1. Create a Storable product with a Route of Manufacture
2. Create a re-ordering rule for this product.
3. As a user with no MRP access rights, create a sale order with this
product and confirm the sale order.
This creates a new `mrp.production` record with `sudo()` on line
\#85: https://github.com/odoo/odoo/blob/fae59cee91969692c2375b3bd37e914ec0fb606e/addons/mrp/models/stock_rule.py#L85
4. Duplicate sale order and try to confirm again.
This produces an access right error because the first loop finds the
existing `mrp.production` record and tries to create a
`change.production.qty` record.
However, the user doesn't have access rights so they get an error.
Solution:
Add `sudo` to the create call.
opw-3508819
closesodoo/odoo#136640
X-original-commit: c5758e122db5396e23a57826a1b12ed7d9765f55
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Andrew Gavgavian (andg) <andg@odoo.com>
In 6698406b92a598f24fa0a778a28b6ef727adc008, we removed action
mrp.mrp_production_report. action_view_mos still using this action, we
change it to use mrp.mrp_production_action instead.
closesodoo/odoo#136382
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
In this viewtiverse, the heroes remove the context dependencies for
`get_views`, from the views and python fields (such as domain). To reduce
inconsistencies and the number of rpc.
Current issues:
* There may be inconsistencies in views at the JavaScript level. Some
overrides modify the behavior of get_views or domains on fields via
context keys, therefore by changing the action, the rendering may be
different. However, these views are cached. However, the cache key
(Javascript) does not reflect the entire context, and requires additional
post-processing from the server.
* Multiple rpc for the same rendering. get_views being dependent on the
context, as soon as it changes, a new rpc is performed. In most cases,
when JavaScript needs the same view, there is no change depending on the
context, the rpc is useless.
* Inconsistency when rendering subviews, some views could be different
depending on the context, this context can be modified in the view itself
via the context attributes. However, the JavaScript client does not redo
an rpc for each change of these sub-contexts. Therefore the result may be
inconsistent.
Solution:
Limit as much as possible the number of context keys provided when calling
get_views, and use the context provided as a cache key. The authorized
keys are 'lang' and '*_view_ref'. For the cache key, options are added in
the get_views method.
Instead of using the context, it is inserted into python expressions.
This will be evaluated by JavaScript and thus avoids inconsistencies.
task-3414108
task-3414068
closesodoo/odoo#135145
Related: odoo/enterprise#47584
Signed-off-by: Raphael Collet <rco@odoo.com>
added a contextual action to call action_plan_with_components_availability()
if each component line of a production order has a forecast_expected_date,
the date_start of the production order will be the latest forecasted date
task 3395161
Part-of: odoo/odoo#129933
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
Commit 167c51b1f9 makes `use_create_lots`
and 'use_exisitng_lots` computed fields in MRP module but did not mark
them as `readonly=False`. Thus, they were readonly by default for any
picking types.
Also, make sure new reception picking type have their `use_create_lots`
set to True and delivery picking type their `use_existing_lots` set to
True.
closesodoo/odoo#135900
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1” with BoM:
- Add a tracked component
- Add another component (no tracked)
- Create a MO to produce 1 unit of the product "P1":
- Confirm
- Unlock the MO
- Set the "to consume" quantity of the tracked component to 0.
- Try to validate the MO
Problem:
A user error is triggered: “You need to supply Lot/Serial Number for
products:”
Solution:
If the quantity to consume is 0, ignore the serial number verification
for this move.
opw-3471256
closesodoo/odoo#135657
X-original-commit: 5e591cf36cdc6dcbdb8a5ee3753247578a771e9f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
If a subassembly was used as component in a finished good and both the
subassembly and finished good were unbuilt, the subassembly could not be
produced again with the same serial (specific use case: medical hardware
refurbishment, medical device is produced/packaged (subassembly), put as
a component into a procedure pack (finished good), both are returned and
unbuilt so the medical device can be refurbished and produced/packaged
again into a subassembly with the same serial).
The _is_finished_sn_already_produced function duplicates domain was
wrongly picking up stock move lines related to the unbuild of the
finished good, making the function wrongly returning True. This fixes
the search domain and adds a test to prevent regression.
closesodoo/odoo#135716
X-original-commit: 4f07b260807053586ac6c01cf92ac3d5e37b1041
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
`_set_dates` didn't work properly with multiple records.
In fact, it only used the `date_start` and `date_finished` of the
first record. The assumption was that `date_start`/`date_finished`
is always the same for each record in self, because it usually
comes from a write call (writing the same values to a batch of
records). But inverse methods are also called by the create
method, and then the previous assumption isn't true anymore.
This bug leads to several inconsistencies between the `date_start`
and the `leave_id`. The `test_replan_mo_without_bom` was fixed in
the previous version, but with the new onchange, it breaks again
because of these inconsistencies.
closesodoo/odoo#135635
Signed-off-by: Raphael Collet <rco@odoo.com>
Fix the issue when update the bom on a draft MO, the product_qty and
product_uom_id will be reseted to 1.0 unit.
The original product_qty and product_uom_id hould be kept when update
bom.
X-original-commit: f1a397ede16c56db3410fd9c5fe387dc98c46422
Part-of: odoo/odoo#135691
Legacy code still use 'onchange' on the 'stock.picking.type' field code
to compute the different xxx_location_id.
As it is no more viable, this commit replace all these onchange by
compute methods.
These changes also has a side effect as some already existing compute
methods now get a set of 'stock.picking.type' in input, such that these
methods are also updated to handle this case.
closesodoo/odoo#134650
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
- Create and confirm an MO with extra components in stock
- Update the quantity to produce
Bug:
the reserved qty is not updated (it actually is but to the previous
value if you update MO quantity multiple times)
since this commit[1] moves are now assigned during the write
before the new product_uom_qty is written on them
opw-3489226
[1]:https://github.com/odoo/odoo/pull/93712closesodoo/odoo#135548
X-original-commit: cc23ebefb4a15d163ec508cd535bf757cf626fa5
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to Reproduce the Bug:
- Create a storable product "P1" with 2 Bills of Materials:
- BoM 1:
- Component: C1
- BoM 2:
- Component: C2
- Create a MO:
- Select BoM 1.
- Save.
- Select BoM 2 without saving. Result: The component C1 is deleted
and replaced by the component of BoM 2.
- Select BoM 1.
Problem:
The component of BoM 2 is not cleared. Because we check if the new BoM
is different from the original one, but since we didn't save the change
when selecting BoM 2, the `move_raw_ids` are not cleared.
Solution:
Clear the `move_raw_ids` if any move with `bom_line` is not linked to
the current BoM.
OPW-3473387
closesodoo/odoo#135044
X-original-commit: f874fd46fcf8c2668c6d2ab42224196868ec0f0a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
- Create a serial tracked product
- Update quantity add random SN
- Edit "ir.sequence" for serial numbers
(search sequence with dev mode enabled)
- Add a prefix for exemple "xx%(doy)sxx"
- Manufacture the product and generate new serial
Bug:
if a serial already exist next number in the sequence will be generated
instead of using the sequence
Fix:
apply same logic than for lots i.e. first generate from sequence then
take next number if it already exists
opw-3291532
closesodoo/odoo#134879
X-original-commit: df96d9ca10c576981f6af79e330b5b46cdeea377
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Usecase:
- Create a BoM for a template
- Replenish 2 different variant
Expected result:
2 distinct production orders for each product
Current result:
A signle production order with the first product variant and twice the
quantity
closesodoo/odoo#134067
X-original-commit: 2a658fb4a509238cd1462e2ffb615ecec05bc2e2
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
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>
To reproduce the issue:
1. Create two products A, B
2. Create two BoMs:
- Product: A
- Component: B
- Product: B
- Component: A
3. On one BoM, open the report "Structure & Cost"
Error: an Odoo Server Error is raised: "[...] maximum recursion
depth exceeded while calling a Python object"
The error occurs because of the cycle between both BoMs. There is
already a check for that in `:MrpBom.explode`:
https://github.com/odoo/odoo/blob/2a73890d304476833d76bac9a36ef92f12f267a3/addons/mrp/models/mrp_bom.py#L329
But it's too late in the flow. We should not be able to configure
such BoMs.
OPW-3200969
closesodoo/odoo#132806
X-original-commit: ba66f6b2ad3ea226779af23cdb4ddf223dd7fe85
Signed-off-by: Adrien Widart (awt) <awt@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
With this commit
================
Removed 'action_mass_start' and 'action_mass_pause' methods also
the 'button_start' and 'button_pending' methods have been modified
to accommodate multiple work orders, ensuring seamless functionality.
closesodoo/odoo#130663
Related: odoo/enterprise#45883
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Before this commit
==================
Marking multiple work-orders as done was not functioning as expected.
Only the first work-order status was being marked as done, and not all of them.
Steps to Produce
================
- Create a bom product having multiple work-orders.
- Create a MO and confirm it.
- Inside WO list view select multiple work orders of the recently created MO,
and click on "done". You will notice that even though multiple work-orders
were selected, only the first work-order status is changed to "done".
With this commit
================
On selecting multiple work-orders and triggering "done" will work as expected,
and the status of all selected work-orders will be marked as "done".
Task: 3374990
X-original-commit: 486aab5ee8ae1cd8792bc9bbb4aae1797c38fe5f
Part-of: odoo/odoo#130663
We only show the move that requires a manual operation in the
shop floor application. Currently we only see the MO for table top
with a single operation to register the finished serial.
It's a bit funnier to see also the components required and check them
Also the manual_consumption field is a compute store without inverse.
It means it's readonly true by default. But we should be able to pass
a value and use it instead of the compute
X-original-commit: 58118291e148a144058c0c883ddd138187a86f3d
Part-of: odoo/odoo#131707
Tejas Modi