This makes the kanban view for pack_operation_product_ids more
consistent with the one for the move lines and also adds the UOM for the
pack operation to the kanban card.
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).
An access error occurs when a the delivery address of a SO is set to a
different partner than the SO partner. In this case, the picking
created is associated to the partner of the delivery address. This is an
issue when the SO partner tries to view the picking from the front-end
("My Account"), since he is not allowed to access it.
opw-681341
Purpose:
For many SMEs, they print the inventory list, and then compare it with their
stocks. It is useful for them to see products with quantity = 0
Sometimes it is useful to see which product is exhausted, to check if it
matches the reality. If the product is not in the list, the user might
think that the system "forgot" about it.
When doing the starting inventory, all products = 0, the users don't want
to add it manually in the list.
Specification:
- Add the possibility to make the inventory of the product category
- Add a checkbox to also select stockable products with a quantity of 0
- Change the order in "Inventory of": it should be
- All products
- One product category
- One product only
- Select products manually
- If "select one product only" or "select products manually" is true,
hide "Include Exhausted Products".
- If "One product only" is selected, it should always display the product, even
if the quantity is 0.
- When the inventory is started, the default sort should be done alphabetically
on the product
- Hide the inventory location if "Manage only 1 Warehouse with only 1 stock
location" is true.
In master , some places the string "Lot" is used and at some places
"Serial Numbers" is used , which is very confusing for the user.
Make a common string "Lots / Serial Numbers" everywhere for the uniformity.
When doing an internal trasnfer, you can choose any destination
location in the header, but not on the line
This is problematic when doing a pick-pack-ship transfer. For the pick
move, you may want to change the source destination location (maybe another
warehouse why not) but as the transfer is already validated you cannot
modify it on the form. But with the Operation Details (Pencil button) you
can modify the source/destination location. The only problem is that a domain
is forcing the user to choose a source destination that is a child of the source
destination on the transfer, which makes impossible to choose a destination on
another warehouse. This tool is pretty much advanced, so we don't need to be so
restrictive.
When doing an internal trasnfer, you can choose any destination
location in the header, but not on the line
This is problematic when doing a pick-pack-ship transfer. For the pick
move, you may want to change the source destination location (maybe another
warehouse why not) but as the transfer is already validated you cannot
modify it on the form. But with the Operation Details (Pencil button) you
can modify the source/destination location. The only problem is that a domain
is forcing the user to choose a source destination that is a child of the source
destination on the transfer, which makes impossible to choose a destination on
another warehouse. This tool is pretty much advanced, so we don't need to be so
restrictive.
1/ In Return form Change the string 'To Refund in SO' to 'To Refund'.
2/ Return form wizard: Reduce the space in header.
3/ Change the button string name 'Reverse' into 'Return'.
Remove no_one group on the Picking waves menu entry.
Add a search on the picking waves in the transfer lists.
Remove the 'Print all Picking' button and add primary button which is 'PRINT' button.
Hide the group in the stock_picking_type form view if in configuration setting:
- Packages: Record packages used on packing is false
- Lots: Track lots or serial numbers is false
Purpose:
Internal note for the moment is useless, unless the warehouse worker
works in the backend.
- changed placeholder of note field
- added note field to picking operations' report
Incoterms models and views are moved in their own file. Impacted:
- stock.incoterms
This commit only moves files. No change is done.
This last commit is done by renaming the remaining code in stock.py file. We
hope this helps keeping a bit of history by being able to retrieve the original
stock.py file.
Procurement model is migrated to new API. No change is performed to code
structure or functional structure. Some code cleaning may be performed when
migrating to simplify the code. Other files may be updated due to the move
towards the new API.
Product models are migrated to new API. No change is performed to code
structure or functional structure. Some code cleaning may be performed when
migrating to simplify the code. Other files may be updated due to the move
towards the new API.
Impacted models
- product.product
- product.template
- product.removal
- product.putaway
- stock.fixed.putaway.strat
Location models and views are moved in their own file. Impacted:
- stock.location
- stock.location.route
- stock.location.path
This commit only moves files. No change is done.
Move model is migrated to new API. No change is performed to code
structure or functional structure. Some code cleaning may be performed when
migrating to simplify the code. Other files may be updated due to the move
towards the new API.
Pack operation models are migrated to new API. No change is performed to code
structure or functional structure. Some code cleaning may be performed when
migrating to simplify the code. Other files may be updated due to the move
towards the new API.
Pack operation models and views are moved in their own file. Impacted:
- stock.pack.operation
- stock.pack.operation.lot
- stock.move.operation.link
This commit only moves files. No change is done.
Warehouse models are migrated to new API. No change is performed to code
structure or functional structure. Some code cleaning may be performed when
migrating to simplify the code. Other files may be updated due to the move
towards the new API.
Warehouse models and views are moved in their own file. Impacted:
- stock.warehouse
- stock.warehouse.orderpoint
This commit only moves files. No change is done.
Picking models are migrated to new API. No change is performed to code
structure or functional structure. Some code cleaning may be performed when
migrating to simplify the code. Other files may be updated due to the move
towards the new API.
Inventory models are migrated to new API. No change is performed to code
structure or functional structure. Some code cleaning may be performed when
migrating to simplify the code. Other files may be updated due to the move
towards the new API.
Inventory models and views are moved in their own file. Impacted:
- stock.inventory
- stock.inventory.line
This commit only moves files. No change is done.
Those models are migrated to new API. No change is performed to code
structure or functional structure. Some code cleaning may be performed when
migrating to simplify the code. Other files may be updated due to the move
towards the new API.
Move models not located in stock.py file and their views:
- barcode
- procurement
- product
- product.putaway, product.removal and stock.fixed.putaway.strat are
extracted from product.py to their own product_strategy file
to separate product and product.template code from stock specific
code related to products
- res_*
- settings
- web_planner
This commit only moves files. No change is done.
Moves performed
- data and demo files are now located inside the data directory
- data and demo files name updated
- report views moved inside report directory instead of views
- main stock menus declarations moved from stock.xml to stock_menu_views.xml
in order to have all main menus in a single file, extracted from model
specific views
- data section of __openerp__.py file reorganized accordingly
No change done in this commit.
This reverts commit a206114d4c.
This commit breaks several of our long standing and widely appreciated policy
- one commit for one feature; do not forget to put the correct impacted addon
- commit message should explain why the change is performed
- a bug fix in master seems weird, why not in stable. If not applicable to
stable the commit message should explain why
- a bug fix in the ORM should come with a test case
- code is not clean
Martin Trigaux