On the BoM structure report the price on line with a
child BoM is inchoerent. Also the sum of all lines in
the report is not always equals to the total of the parent
line.
For the first issue, it happens due to commit 17b6256955
that use the number of operation cycle as quantity.
The second issue happens because sometimes the rounding is not done
at the smallest level and thus the rounding of the sum is different than
the sum of the rouding.
- 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
Usecase to reproduce:
- Create a BoM that create more than 1 finished product
- Use a routing
- Open the BoM structure report
The operations time from the routing are multiplied by the quantity show
on the report.
It should not happen since routing's operations are not by unit.
If a user create a BoM that produce 50 finished products then the
operation time is always the same when the user produce between 1-50
units. It then double from 51-100,... (workorder use the same process
for the expected duration).
This commit fix this behavior by using a rounding up on the
quantity asked on the report / BoM product quantity.
It also take care of the workcenter capacity.
opw-1890005
Usecase to reproduce (chrome):
- Create a BoM with float quantity in component
- Print the BoM cost and structure report
When using a type="number" on firefox it is not possible to use a
decimal. However on chrome there is no restriction and a decimal
could be use. It makes senses to be able to work with decimal
(e.g. the UoM is in kg)
It also exists an explicit cast to integer since data are received as
string from the javascript. However since quantity displayed could be
decimal, the cast should be adapted to float.
Closes#27464Fixes#27437closesodoo/odoo#27522
Purpose
=======
They are a lot of places where we set an attribute 'groups' on a view element and:
- The group doesn't exist anymore
- The group xmlid is not correct
- The group xmlid exists but the modularity is not respected (example: group_stock_user
used in a view in the 'product' module).
Where it happends, nothing warns the user of the developer. The element is just never
rendered.
Specification
=============
Fix the occurences of bad groups definition
Calling `html_container` is not only useless when using the `basic_layout`
but it's also dangerous because it is already present in the latter.
The assets will be added twice in the report (once in the head and once in
the body).
Morever, the <base> tag was added in the report ; this tag is only useful when
rendering the pdf version, which uses minimal_layout that already set the
<base> tag ; this tag can only be present once in an HTML document so it has
been removed from the BOM report.
This results in a report not being editable by Studio.
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"
In the current code, we only show a PDF previewer if a PDF is already
saved. When the PDF is changed we see the preview if it was previously
saved also.
This seems to be the expected behavior, but this changeset changes it so
we could always show a preview.
opw-1888399
closes#27393
- Create the following BOM for 100 Units of A:
15.0 kg of C1
1.0 kg of C2
500.0 g of C3
- Click on 'Cost & Structure'
The quantities and costs of 100 Units are used for 1 Unit.
opw-1886959
Since the product configurator it could exist a product.template
without product.product (variant selected on SO/PO). however the
bom cost and structure report needed at least one product.product
This commit modifies the bom report in order to use the standart price
of the product.template instead of the product.product since it's the
same. It also adapt the search on attachment.
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"
Christophe Simonis