Display a BoM.
On BoM lines, there is an attachment feature that creates a mrp.document,
which is basically a container for an attachment.
This commit fixes the view which displayed 'no attachment' when there were some
and vice versa.
It also fixes the computation of the number of attachment: the displayed view is
on mrp.document, but the computation is done on ir.attachment.
As a result if there are other unrelated attachments (such as digital files)
they would be counted but not displayed.
opw 1923441
closesodoo/odoo#30208
This commit has several parts:
- fix ordering of attributes and values
- fix/create python logic (notably for checking the possibility of a combination
and for price computing)
- fix currency
- display correct info on the views without the need of JS (prevent flickering)
- fix various issues with website and SO
- add a lot of tests (both unit and tour)
================================================================================
*** Make consistent the filtering and ordering of product variants ***
Filter & Check possibility
==========================
The first variant shown on the website should always be possible.
When activating the customize "list view of variants", we don't want to show
impossible combination on the list.
We also don't want the user to be able to add to cart an impossible variant.
Show appropriate messages when no combination is possible.
Order
=====
We want the variant order to be consistent with what the user selected with the
sequence fields. The display order on the website should be the same than the
display on the various backend views.
This implies also fixing the order of:
- product.attribute
- product.attribute.value
- product.template.attribute.line
- product.template.attribute.value
The general order is now: (parent,) sequence, id.
Before, it was already a mix of those, but not always in the same order, and not
every key for every model. The name has been removed from the order: either we
sequence them correctly, or we want them in the creation order.
On the website, the first combination shown by the python should be the same as
the one that will be computed by the JS to prevent flickering.
Ideally there should be no RPC at page loading if the python has computed
everything correctly, but it is currently not possible to achieve because the
view logic for website_sale_stock is only in JS.
================================================================================
*** Fix product template and variant price computation ***
Move and improve the get_combination_info method:
- take into account tax included/excluded settings (B2B/B2C)
- take into account pricelist discount policy (striked price)
- fix inconsistencies when price after pricelist would be 0
- use proper rounding and discount compute with the currency helper methods
- fix an issue where context "partner" would have a mix of id and recordset
================================================================================
*** Fix currency conversions ***
The list_price and lst_price of a product are always encoded using the currency
of the product.
The results of "combination info" are always returned using the currency of the
pricelist if given, or the currency of the product.
The prices on an order (line) are encoded with the currency of its pricelist.
================================================================================
*** Fix dynamic variants access rights ***
Public users on the e-commerce should be able to create product variants if the
configuration of the attributes of the product template is set as "dynamic".
This uses "sudo" to bypass create security rules for public users.
Multiple checks are done to ensure that it creates a valid product variant.
================================================================================
*** Miscellaneous bugs, tracebacks and necessary improvements ***
In general:
- correctly show warning when no variant is possible
- don't let user add to cart an impossible variant (from optional product
modal or from any RPC), both in interface and controller logic
- fix as much flickering as possible by correctly pre-computing in python/views
- move business logic from controllers to models
- correctly add no_variant and is_custom values on the SO line description
Sale order:
- fix traceback when emptying the product_id field from configurator
website_sale:
- correctly compute first image / carousel, and correctly swap images when
changing variants, without duplicate image or zoom problems
- don't use list view of variants when it doesn't make sense
- added missing product info when adding a no_variant attribute to cart
- fix cart accessory product computation
website_sale_wishlist:
- fix it with dynamic variants, no_variant and is_custom
website_sale_comparison:
- fix it with dynamic variants (comparison and alternative products)
website_sale_stock:
- fix it in general (some flickering still present)
================================================================================
Authored by @seb-odoo with contribution from @awa-odoo
task-1910821
closesodoo/odoo#28079
Usecase to reproduce:
- Set manufacture step to 2 or 3 steps
- Create a MO
- Go on the PC picking and validate some quantities w/h BO
Traceback because there is no documents to log the activity.
It happens because the function used in groupby and sorted
(in the method _log_less_quantities_than_expected) expect a picking.
The purpose of _log_less_quantities_than_expected is to generate
an activity on the next picking in order to notify that some quantities
will be missing due to the cancelation of the back order. In order
to find the following picking it uses the destination moves from the
current's picking moves.
Picking w/h BO Next Picking (activity to post)
| |
moves -----------> destination moves
However in the case of 'pick components' picking type(PC) the destination
moves are linked to a manufacturing order and not a picking. So it
_log_activity_get_documents return an empty parent since picking_id is
False.
In order to fix it, _log_activity_get_documents only add the tuple
(object where the activity should be log, responsible for the activity)
if the object is not False. It also add a hook in order to add
(mo_id, repsonsible) during _log_less_quantities_than_expected on top
of (picking_id, repsonsible) in order to log activity on MO directly
linked to PC.
This commit also add a missing precision_rounding in backorder
confirmation
opw-1908753
closesodoo/odoo#29385
Set a BOM to create 10^k units of Product P, using n units of raw material R.
On R, put rounding to 1 unit.
Create a MO to produce 1 unit of P.
Since it needs n/10^k units and rounding is set to 1,
it sets 1 unit of R to consume.
Now "update" (quantity to produce) to 10^k'.
It correctly updates the quantity to consume.
However, since it doesn't update the unit_factor, when you "produce",
it will consume 10^k' units instead of 1.
We copy the way the unit_factor is initially computed when updating the lines.
opw 1903776
closesodoo/odoo#29067
Once we log an exception via next activity in a production, we search moves that have been updated uphill to write the useful information about the change. The issue is by default, the key 'move_orig_id' is searched while some moves could be linked with 'created_purchase_line_id' key.
This commit avoid mapping 'move_orig_id' on empty recordset and so avoid a traceback.
opw:1911399
closesodoo/odoo#29087
- Create the following BOM structure:
```
Prod 1 (Manufacture)
|
--- Prod 2
Prod 3 (Kit)
|
--- Prod 4
Prod 5
```
- The BOMs for Prod 1 & 3 must have a routing set, to generate
workorders
- Create a MO for 1 unit of Prod 1, process to the end
2 units of Prod 1 are created instead of 1.
This is due to the WO for Prod 3 not having a `next_work_order_id`.
Therefore, `record_production` adds an extra quantity at:
```
production_move.quantity_done += self.qty_producing
```
To prevent this, we set as `next_work_order_id` of the BOM of Prod 3 the
WO of Prod 1.
Closes#19527
opw-1817398
opw-1883693
- 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
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
Fine tuning of 00bf6709a8.
Let's consider two variants V1 and V2
The function check_cycle was too restrictive, it didn't allow
to create a BOM for V1 with a dependence to V2.
But a common use case could be for example:
A black T-shirt made from a white T-shirt and black color.
opw:1911622
closesodoo/odoo#29075
Let's consider two variants V1 and V2
The function check_cycle was too restrictive, it didn't allow
to create a BOM for V1 with a dependence to V2.
But a common use case could be for example:
A black T-shirt made from a white T-shirt and black color.
opw:1911622
closesodoo/odoo#29038
Steps to reproduce the bug:
- In the Manufacturing App , enable Work Orders and Quality
- Configure your products,BOM and Routing
- Create steps in routing with type='Register Consumed Materials'
Bug:
When you finished your Work Order operations it displayed "False" value in
the "Finished Steps" tab instead of the uom of the finished product.
Technically:
The function "record_production" unlinks the temporary stock.move.line that can
be linked to a quality.check. So the component_uom_id of the quality.check could not
be found when computing the field 'result' on model "quality.check' with function "_compute_result".
opw:1909768
closesodoo/odoo#28865
Usecase to reproduce:
- Install a database with demo date and mrp or purchase
The buy/manufacture rules have a wrong company for warehouses
in company 'My company, Chicago'
It happens because the warehouse is not specify in the create
values. In this case it creates the rules and set the user current
company as default.
This commit specify the company during the create call.
closesodoo/odoo#28682
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
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
Nans Lefebvre