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"
In order to implement the next version of the dashboards in enterprise
we need to make some changes in community namely :
* Modify some search views (used in the dashboards)
* Remove the date/datetime filters from the search views as they are
duplicated with the time ranges
* Rename the menu items from Dashboard to Overview
Mrp workcenters have a resource_calendar_id to specifie its working
hours. On the form view, this field is optionnal but is mandatory in the
form view.
This commit set it as required in the view to avoid the classical 'object
with reference * - *' error.
Task : 1876847
The pdf_viewer widget has been moved from mrp to web in rev. odoo/odoo@a7b521f
but the corresponding style was still in the mrp module. It's now put in the
right place.
Closes#26449
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
Rename 'Reason' in 'Blocking Reasons'.
Rename 'Effectiveness Category' in 'Category'.
Remove 'Is a Blocking Reason'.
'manual' field become a technical field.
workorder: Change label Efficiency -> Productivity.
The purpose is to make it easier for the user and remove
blocking keywork since it's already in productivity losses views.
Related to task: 58625
PR #23341
When the MO is done, the reserved quantity on stock move is equal to 0
and decoration-success, decoration-danger, decoration-muted are all set
on the class. That implies an uncertain result.
This commit clarify the situation by applying
- decoration-muted if the MO is done
- success, danger or none otherwise
Related to task: #1862299
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.
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).
The '.badge' elements must now also use the 'badge-pill' class to get
the same style as before as '.badge' elements without it are meant to
replace the old 'label' component.
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
This commit hides the field 'Routing' and column "Consumed" in manufactoring
order if the product to make is of type 'kit'. Those field are specific
to manufacturing products
PR:22085
TASK:38933
This commit hide 'Planned' filter and 'Routing' group by if work order
feature is not actived As they only make sense in that case.
PR:22085
TASK:38933
The default resupply feature can be configured by going on the route and activating
it for the warehouse. This field is therefore useless and this commit remove it.
The field 'resupply warehouses' is reworded an hidden when there is only one active warehouse
PR:22085
TASK:38933
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.
It is now possible to easily filter data using periods of time
(e.g. Creation Date: This Week). This adds greater flexibility to the search
view and has made some old filters become useless. In this commit, we alter
the search views in order to profit of the new framework possibilities.
Christophe Simonis