- Now, the fields date_planned_start and date_planned_finished is
required in views, because it was strongly related to the leave date_to, date_from
which are required.
- Change the name_get in case of single WO in MO and replace the dot
by a dash.
- Improve the WO form view to be more responsive when it is open from the
gantt view.
- Change name of a Operation in the demo data
task-2169447
Ensure proper domains are applied and enforced on relation fields thanks
to the `check_company` attributes.
Make sure unbuild have proper sequence for each companies.
The produce wizard and workorders company is the one of the production.
The BoM line company_id is the one of its bom_id.
Added some tests.
task-1985992
image_original => image_1920 (now resized to 1920)
image_big => image_1024
image_large => image_256
image_medium => image_128
image_small => image_64
image replaced by image_1920 (when writing) or by image_1024 (when displaying
what was previously the big size)
+ add new intermediate format:
image_512
PR: #34925
When creating a manufacturing route in 2 companies in a multi-company environment,
only the routing 's reference of 'My company' got a sequence but the routing 's reference
of the other company stayed 'New'. Now the default sequences for mrp.routing are shared
between companies like SO and PO.
opw:2008570
closesodoo/odoo#34169
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Change the use of Inventory Adjustment, notable changes are:
- Removed filter field: When user creates a new inventory
adjustment, he can set one or multiple locations and/or products.
An inventory adjustment will worry only about defined
locations/products, but if neither product or location was set,
it'll manage all stock.
- Inventory Adjustment Lines have their own view instead of be
listed on the Inventory Adjustment form view.
Inventory adjustment lines have new color legend:
- Red: The quantity is outdated.
- Blue: There is difference between the on hand quantity and the
counted quantity.
New inventory lines created by the user are written in bold.
- User can't modify already existing inventory lines, except for the
counted quantity.
- When an inventory line is outdated, the user has the possibility
to select and update it, that'll recompute the on hand quantity.
- When an inventory adjustment is validated, it will take in account
only the difference between the theoretical quantity ('On Hand
Quantity') and the counted quantity to adjust the quants.
- When an inventory adjustment is canceled, it will keep its
inventory lines and won't regenerate them when re-started.
- When an Inventory Adjustment generates Account Moves, user can now
find them in a stat button in the Inventory Adjustment form view.
Also, made some changes in demo data to match new requirement.
Task #1935921
This commit ticks the 'Create component lot' checkbox for
the demo manufacturing operation type of first warehouse.
This change will leave the default behaviour for all warehouses
but tests with demo data are now more straightforward and do
not demand too much parametrization
Task : 1970450
closesodoo/odoo#32772
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Technical refactoring in order to set by-products the same way
than raw materials. Before this commit byproduct were always set
at the last workorder or automaticaly set at the end of produce
wizard with the same quantity than in the BoM. In order to modify
it, the user has to produce the finished product then unlock and edit
the finished move line linked to the byproduct. In this commit, the
user could specify at which workorder the byproduct is created and
he could directly specify another quantity done in the produce wizard
inside a specific tab for by-products.
Technicaly, abstract workorder will add a new many2one key on workorder
line in order to set 2 different one2many (one for finished goods and
the other for raw materials). The key is set depending the many2one
key for production on the linked stock move. On the by-products itself,
it is now managed as a workorder line, thus the code to generate them
and transform them in a finished stock move line is the same than for
the raw components.
Commit 5ef46664a2 share code between produce
wizard and workorder. Field final_lot_id is now commonly used but not very
well named. This commit rename it into finished_lot_id as it represent the
lot number of the finished product.
Task : 1998064
closesodoo/odoo#32761
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose: The quantities to consume on Bill of Material lines should be
either strictly used or be taken as a reference more or less adjustable.
This commit adds a setting on BoM to specify if the consumption is 'strict'
or 'flexible'. This new option has the following impacts:
On produce wizard: if consumption is set to 'strict', the done quantities
are prefilled and checked when saving the wizard. If set to 'flexible',
the production flow remains the same as present one.
On workorders: if consumption is set to 'strict', the Validate button
will save the consumed data, and propose to fill the remaining ones until
the total is registered. If set to 'flexible', two button are displayed.
'Validate' to register the current component and pass to next step either
the quantity to consume is complete or not, and 'Continue Consumption'
to registered the current component quantity but leaving the user the
possibility to add more quantity (and possibly another lot number) for
the current component
This commit also revert partially d3617fd852
as the warning become some sort of an error
Task: 1889393
To record a production via a manufacturing order, the user can either
use the produce wizard or the workorders views. Those two objects was
technically different but act more or less the same. This commit aims to
merge the similar behaviors in common code
We introduce two new abstract models :
1. Abstract workorder to share workorders and the produce wizard
2. Abstract workorder lines to share active_move_line on workorder and
product_produce_line on the wizard. Those abstract line keep the information
about the quantities and lot number to put on component move lines and
finished product move lines
Task : 1891864
The purpose is to be able to plan manufacturing order
without propagate the components's documents directly.
Except when the manufacturing comes from a pull rule, it will
be confirmed directly.
In order to do it, it will just create the moves without confirm them.
They will be only confirmed after a 'Mark as Todo' click.
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
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.
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
Create new methods on `BaseModel` to create records with given xml ids in
batch. Those methods replace the methods `_update` and `_update_dummy` of
model 'ir.model.data', which are now deprecated.
Adapt XML and CSV import code to create records in batch.
PURPOSE
=======
1. Unified product demo data
2. Less demo: one per use case
3. Demo data for all models
Specification
=============
1. Refactor all the brol in the demo data
2. Adapt the tests to make them green, as some products are
renamed, removed, created in python instead of as demo data
...
The method 'action_done' on inventory adjustment became private and the
action launched from the view is now 'action_validate', so we adapt
those tests to use the new function.
TASK-30921
Current demo data do not have advanced configuration.
This commit provides new demo data in order to test
bom report or advanced MRP configuration with sub bom
bom with kit,...
Moves UoM models, test and data to a new addon in
order to be able to use uom without product.
A simple example is be to be able to use UoM for
timesheets.
This commit only move code, and adapt xml ids
without chaging any feature or functionnal
behavior.
Note: 'product' module now depends on new
'uom' module.
Purpose
=======
As the 'function' tag is re-evaluated on the module update (even when noupdate="1"), the ir.model.data will be created a second time with the function 'create'.
This leads to the record deletion after the update when calling '_process_end'.
Specification
=============
Use '_update' instead of 'create' and '_update_dummy'.
- _update won't create another ir.model.data if it already exists.
- _update already calls _update_dummy to avoid the record deletion.
Use case to reproduce the bug:
- Enable multi company and create a second one.
- Add both company to another user and give him stock manager rights
- Login on the second user and select as active the created company
- Go to product and create one
-> access right error on stock.location.route message.
It happens because the routes 'buy' is selected by default.
However the route buy when created use the default company
although it's generic for all companies.
This commit change the data in order to remove the company on
routes buy, mto, manufacture and drop_shipping. Since this commit
was released after v11 release, it could happens that already created
database still have the problem thus the solution is to remove
manually the company on the routes quoted above.
opw-777718
When producing a finished product with a lot, also the raw materials
without lot tracking should split the move lines to at least know the
quantities consumed for every lot produced. This way, the traceability
report will not confuse the user.
This revision changes the BOM and routing of what was previously a
"computer desk". The aim is to provide a complete example which can be
used to showcase what can be accomplished with the new tablet view.
The production wizard raised a traceback when you were trying to consume
product tracked by lot without reservation.
To fix this issue and some potential others, we have removed the
move lines from the wizard and create produce lines that are used on
validation to create the move lines.
This also let us show the 'To Consume' quantity of a lot instead of the
reserved quantity which has no sense when there is no reservation.
This removes the procurement.order model. To fufill their needs SO, PO, MO and
stock moves now call the _run method of the relevant procurement.group.
This mecanism is now only used for stockable product, tasks now uses their own
independent mecanism.
The _run method will check all the applicable rules and create directly the
needed model to fufill the need.
The modules stock, purchase, mrp, extends the _run method to implement their
specific strategy relevant for the rule type they define.
If an exception happens the message will be logged as a mail messsage on the
source model, for example, if a sales order cannot be fufilled the salesperson
will now see directly the reason.
OLD commit messages:
[WIP] procurement: removing procurement.order in stock, sale, purchase, sale_stock. WIP
fixup! [WIP] procurement: removing procurement.order in stock, sale, purchase, sale_stock. WIP
[IMP] Basic tests
[FIX] test not necessary anymore
[FIX] remove unnecessary print statement
[FIX] unnecessary test + why passing warehouse worked before?
[IMP] purchase: one move by purchase order line
[FIX] purchase: correct inventory tests and pass move_dest_ids among procurements
[FIX] because of bad cherry-pick merge
[IMP] make mrp pass by adding move_dest_ids there too
[IMP] tests of sale_mrp, no need for cancelpropagation then
[IMP] better to consistently use recordsets also for one2many
[FIX] purchase_requisition
[FIX] Exceptions should trigger errors, which should be caught in the tests
[FIX] sale_mrp: remove usage of procurement.order and use sale order name instead of sol
[FIX] stock_dropshipping: add sale_line_id on purchase_line_id
[FIX] Remove pdb
[IMP] add stock_dropshipping files
[IMP] stock: search carrier through sale line instead of procurement group
[IMP] add procrule test and preision needed when updating sol
[FIX] sale_order_dates + [IMP] procurement exceptions by scheduler
[FIX] No need to return task
[IMP] move file as name changes and add corrections
[FIX] Continue Run Schedulers wizard fix
[FIX] name issues of takss
[FIX] updating sale order line, but there is still a problem with the recompute
Currently there is no default resource calendar. This leads to calendar
being rarely used as it is not clear how to define them and how to use
them. Moreover some code handle default-like calendar by trying to
use 8-16 work hours; this should be replaced by having a real default
calendar.
This commit replaces the demo calendar by a real data calendar. It will
soon be used as default everywhere a resource calendar can be defined.
Future improvements will come to make resource easier to use and clean
its API. This commit is only the beginning !
Several modules defines records with the external ID `base.foo_bar` while it is
created inside this module (typically menus and groups).
While there is no technical reasons to do so but this may introduce issues:
- these records will not be deleted during uninstall
- if a language is loaded before the installation of the module, it won't be
translated
The uninstallation will only remove the records with an external id linked to
this module (these would only be removed when removing base).
Installing a language before the module will drop the translations not linked
to an existing external id (as it can not be resolved).
This commit correct all the external ids tagged as from base or other incorrect
modules.
This commit contains the core of the new MRP. It contains a whole refactoring
of the MRP application, with improved and new features, written in new API.
Among other here are the main manufacturing workflow improvements :
- Picking type not only for pickings but also for manufacturing orders
- Properties replaced by picking type
- BoM can only be produced with its routing (no other)
- Either produce without routing with only production orders, or produce with
routing
- By default, there is an order in the work orders (serially), but you can
override it to be able to work in parallel
- Time clocking on work orders and block time on work centers with reporting
on OEE, performance, losses, ...
- Real-time adaptation of timings on operations
- Lots/serial numbers can be inputted like in the pickings on manufacturing
orders. It is also possible to input them in the work orders.
- Material availability independent of production order state (possibility to
start production when only part of it is there)
- Work sheets on work orders
- Put messages on work orders to make your workers pay attention to something
- Full traceability link to see for each produced piece of stock, the
consumed pieces, ...
- Separate scrap object (a scrap is not done based on an original move
anymore)
- Separate unbuild system (if you want to unbuild into its original
components)
Thanks to all people that helped during this development, notably but not
limited to Chirag A Dodiya (cod@odoo.com), Gaurav Panchal (gan@odoo.com),
Jignesh Rathod (jir@odoo.com), Mansi Trivedi (mtr@odoo.com), Pariket Trivedi
(ptr@odoo.com).
Split files and move them according to the new API guidelines. Containing
- mrp splitted into its main models and files
- stock code moved into its own models and files
- various renaming
Rémy Voet (ryv)