- Create 2 Products A and B, tracked by serial number
- Create a BOM for A:
1 Unit of B
- Create a MO for 2 Units of A
- Validate:
Product with S/N A1 consumes B1
Product with S/N A2 consumes B2
- Unbuild A2
If A1 was created before A2, B1 will used as a component of A2 at
unbuild.
When going through the stock move lines, we don't verify that the lot
produced matches the lot we unbuild.
opw-1889002
closesodoo/odoo#28154
This reverts commit d78b6f5e25.
This constraint is considered too harsh. It was applied to circumvent
inconsistencies when a bom is modified while being used in a
manufacturing order and the user chose to update the quantity to
produce. The current code will look at the existing move if no
intermaddite post of inventory was done else look at the new bom.
A code to re-construct the original BoM from the stock moves isn't easy
to write to handle all cases, one particularly complicated is the
deletion of bom lines of the same product.
We also considered to block the update qty button if the bom is modified
after the create date of the MO, but if we have to read all the bom
lines of all the sub bom in a computed field it may be slow on large
databases.
We thus chose to remove the constraint and think of a better approach in
a future version.
task 1891407
closesodoo/odoo#28155
Usecase to reproduce
- Enable multi locations, multi routes
- Check mrp 3 steps on warehouse
- Create a MO
Raw moves are duplicated. It happens due to commit aeb038747f
The purpose of the commit was to split the rules from SAM to stock.
The pull rule should be in manufacture route and the push rule on the
warehouse. However the push rule was not correctly copied and created a
push rule from prod to sam instead of sam to stock.
Fixes#27962closesodoo/odoo#27965
Producing a manufacturing order on components with more than one unit
could leads to multiple move line reserved on this component. Marking the
workorder as done, in that case, will trigger an error saying "Cannot set
the done quantity from this stock move, work directly with the move
lines". Instead of setting the quantity done directly, this commit
uses the magical function _set_quantity_done() that manage the case
of more than one move lines.
OPW-1888780
closesodoo/odoo#27773
Swiping a credit card through pos_mercury no longer worked on the
payment screen.
3a74afd21e introduced some special code
in BarcodeEvents for mobile Chrome. This code relies on an invisible
input being filled in by barcode device. On the payment screen the POS
uses a keypress event handler on body to manage input. This handler
preventsDefault which stops the input from being filled in.
It's worth noting that this new approach in
3a74afd21e is not fully equivalent to
the original barcode events handler. Events are not redispatched, so
this effectively disables keyboard input on the payment screen (or
anywhere where it is used).
opw-1888466
closesodoo/odoo#27820
Producing a manufacturing order on components with more than one unit
could leads to multiple move line reserved on this component. Marking the
workorder as done, in that case, will trigger an error saying "Cannot set
the done quantity from this stock move, work directly with the move
lines". Instead of setting the quantity done directly, this commit
uses the magical function _set_quantity_done() that manage the case
of more than one move lines.
OPW-1888780
closesodoo/odoo#27773
This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
Targets commit d3530eb07e
Purpose
=======
[Follow up AL review]
Code cleanup and some improved models naming for the product configurator feature (see targeted commit).
Mostly changes the "product.attribute" related models.
Updated models:
- "product.product.attribute.value" to "product.template.attribute.value"
- "product.attribute.filter.line" to "product.template.attribute.exclusion"
- "product.attribute.line" to "product.template.attribute.line"
Updated fields:
- [sale_order_line in sale/sale.py] "product_custom_variant_values" to "product_custom_attribute_value_ids"
- [product_template_attribute_value in product/product_attribute.py] excluded_for is now a o2m instead of a m2m
- [product.attribute in sale/product_product.py] "create_variant" field is now a Selection with "no_variant" (old false), "always" (old true), "dynamic" (new value)
- [product in product/product.py] "product_attribute_value_ids" to "product_template_attribute_value_ids"
Purpose
=======
Product attributes can be configured to create variants "on demand".
This means that product.templates having these attributes will only create product.product variant
when that combination is actually selected in a sale order/in the web shop.
Product attribute values are also improved to handle extra prices and exclusions
in all three modes ("never", "on demand", "always")
Specification
=============
Create variants on demand
- add a new mode to generate variants as they are added to the order/cart
(needed for big # of combinations managed in the inventory and/or produced in mrp with specific boms)
- replace the boolean by a selection radio
tooltip for this new field:
Always:
Variants are generated straight away when
the attribute values are combined in the product configuration.
Only when the product is added to a sales order:
Variants are generated once the combination is selected in the sales order.
This is advised when variants are customized on demand and manufactured as such in Odoo.
Never:
Advised when variants are not needed in Odoo.
The selected values just show up in the description of sales order lines.
- ability to define attribute extra prices & exclude combinations in all variant modes
- if at least one attribute of the product in set to "on demand" mode, generate all the variants "on demand"
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
mrp.workcenters are resources instances. Their resource_type is human by
default while workcenters should be considered as material. This commit
set the resource_type as material by default in case of workcenter
No picking_type_id is set on move created in Manufacturing orders, so
when you sort/group by your all your moves in a tree view, you cannot
easily identify the ones that belong to Manufacturing orders.
So we've added the picking_type_id of the MO on the moves, but also had
to addapt the condition to know which move having a picking_type_id and
no picking must be assigned to a picking.
opw:1863591
When modifying a BoM that is used in a MO not done, raise a blocking
warning to avoid inconsistenties at production.
Proudly pair programmed with pim <pim@odoo.com>.
Some mrp tests has been adapted to not raise the new error. They used
demo data while they should created inside the test.
This commit is related to task id : 1855566
For example: I want to consume a component A if the product is grey OR yellow.
Currently,the component A will be consumed if the product is grey AND yellow. But this variant never exists as grey and yellow are values for the same attribute. So if the values are for the same attribute, odoo should check for a product that is GREY OR YELLOW (and not GREY AND YELLOW).
TASK-ID: 1865604
Currently if the user want to apply the stock after manufacturing push
rule, he has to select manufacture rule on the product. That could be
easily forget by people not used to rule and route.
In order to avoid the push rule will be applied on warehouse. That means
the user don't have to select the route on the product and it will apply
depending the warehouse.
The pull rule stay on the manufacture in order to avoid confict with
reception route/rule.
When a final product move line is shown in the traceability report is
displayed, the reference to the MO is not displayed because the finish
products move lines don't have any productio_id on it.
So to fix this we take the production_id of the move_id when it's a
finished product, and the raw_material_production_id of the move_id when
it's a consumed product that are always set.
TASK-ID: 1873101
When users create new productivity losses of type productivity or performance,
they could not be used. Only one is selected randomly. So it makes no sense to allow
that configuration.
Related to task: 58625
Usecase to reproduce:
- Check manufacture to resupply and manufacture in 2 or 3 steps
- Uncheck manufacture to resupply
pbm and sam rules in global route(mto/manufacture) are still active
It happens because the condition to archive the rules was not complete
the check on manufacture to resupply was missing
Warehouse's routes, locations, picking types and
sequences are now generated on create or with a post
init hook for exisiting warehouses before module installation.
Before the init hook, warehouses created before mrp module installation
do not have a specific sequence number for manufacturing and they
shared the same sequence production created in data.
Pickings/MO/SO/PO can be linked. Only the increased quantity is
propagated between documents. However their ordered quantities can
also be decrease or they can be cancel. In this case an activity
is created on impacted documents in order to describe the situation
and inform the user that a manual action is probably require.
Also in order to propagate the increased quantity from a MO, we have
to do important modification in MRP and we want to avoid doing it before a
major release. That's why increased quantity on a MO also work with
activity at the moment.
The purpose is to split up the supply chain in different group.
Currently if a user create a SO with a MTO manufacture product
that use MTO/buy components.
SO cancellation will:
- Cancel all the pickings including pickings between MO and suppliers.
- Log an activity on the MO but not cancel it.
We prefer cancel all transfers between SO and MO when the SO is cancel.
Cancel all the transfers between MO and suppliers when the MO is cancel.
Create a new procurement group when the _run_manufacture method is call
allows to achieve this behavior.
Currently MRP do not handle multi locations for components. In order to
be able to use both feature at the same time, we could:
- Improve mrp in order to handle multiple stock.move.line for a
componenet stock.move
- Add a rule that allow to bring all the good from multiple location to
a single location. (was already possible but it requires some
configuration)
This commit introduce a checkbox on the warehouse in order to
automatically configure all the routes/rules/locations/picking_types,...
necessary to bring all the components to a single location before
running the manufacturing order.
Technically it also refactor some stock_warehouse.py methods in order to
easily override the picking_type, rules and routes creation.
Thank to Hetashree Chauhan <hch@odoo.com> for his help.
task_id: 27785
The commit cfbfaf38be283e68c5a923ff2aafd1293135c4f1 remove the views and
menus related to mrp.message. This commit complete it by removing the
model, all the related fields and the access rules
In purchase we add a stat button that counts the number of purchase
orders linked to the product.
In this commit we change this count to count the quantity of products
linked to a purchase order.
We basically do the same thing with the stat button of sale (sale
orders) and mrp (manufacturing orders).
Finished product moves from a MO where created without warehouse_id.
It implies that push rule based on warehouse where not trigger on those
moves confirmation.
This commit adds warehouse_id on unbuild/production's finished/raw
moves. It also add a test for this behavior.
Task ID - 1865574
When a product variant is set on a BOM, the column 'Variant' of bom
lines is hidden as all lines will be applied for the specific variant.
If there was any variant were set in this column, they are removed as it
doesn't mean anything because we are working to a specific one.
TASK-36708
Usability improvement:
- Common view for push and pull rules
- Add an help text in order to describe the rule
- Rules menu
- Warehouse checked by default on route created by a warehouse
- Lower the MTO route sequence in order to take it first.
- Tooltip cleaning
Technical improvement:
The purpose of this task was also to merge stock.location.path(push rule) and
procrement.rule. Those two model were design to execute the same task
but in a different direction. Thus it contains duplicate code.
Task ID 1852969.
Task 40692
Various changes to import/export (mainly) UIs:
* default to excel & "full" (non-import-compatible) export
* auto-detect encoding of CSV using chardet
* remember column -> field mapping after having imported a file (useful
for repeated imports where auto-matching failed)
* better handle localised booleans & column names
* automatically select source list view's fields when exporting
* better integrate import templates feature and add a number of templates
Christophe Simonis