product_uom._compute_quantity is an ensure one multi method taking a browse
record as second paramter. It replaces _compute_qty and _compute_qty_obj
to have a single and standard computation method.
product_uom._compute_price() is now an ensure_one multi methods, taking
a browse record as second unit. This helps simplifying and unifying the
various calls and price computation methods.
Commit 4326d864 removes the inverse function of the `date_planned`. This
is necessary to avoid unexpected changes of the scheduled dates.
However, this removes the ability to set the scheduled dates of all
lines at once.
This commit introduces back the functionality thanks to a new button.
This way, the functionality remains without unexpected behavior.
A misleading behavior occurs with the recomputation of scheduled date.
Here is the use case:
- Create a PO with 2 products
- For the product 1, set the scheduled date to today + 7 days
- For the product 2, set the scheduled date to today + 14 days
When saving, the scheduled date of product 2 is reset to today + 7 days.
This is of course unexpected, but moreover, a different behavior can
happen depending on how the scheduled dates are modified. In the
previous case (both products have now the same scheduled date), one can
observe 2 situations.
Case 1.
For the product 2, set the scheduled date to today + 14 days and save.
In this case, the scheduled date of product 2 is not reset.
Case 2.
- For the product 1, set the scheduled date to today + 8 days
- For the product 2, set the scheduled date to today + 14 days
In this case, the scheduled date of product 2 is reset to today + 8 days
when saving
The reason of a different behavior in the 2 situations is that the
scheduled date of the PO is changed in case 2 and not in case 1. Since
the scheduled date of the PO is changed, it triggers the inverse
function `_inverse_date_planned`.
When saving, it is not possible to know whether the scheduled date of
the PO was changed on purpose by the user or recomputed. There are 2
solutions to get a consistent behavior:
- Force the scheduled date of each line to be the same than the
scheduled date of the PO. However, this makes the scheduled date of
the line useless.
- Do not change the scheduled date of the lines when the schedued date
of the PO is changed. However, this removes the ability to reset
automatically the scheduled date of the all lines at once.
This is the second solution which is chosen with this commit.
opw-682934
opw-684063
Closes#12904
* All methods are converted into an api.multi style (using ids instead of
a browse record or an id)
* Removed api.v7 methods for two methods defined in purchase and overriden
in stock_calendar, now used only in a true multi-style (old and new API)
* Moved methods having orderpoint as primary object on the orderpoint model
* Removed unused next_day field on resource.calendar model; it was
introduced with hacks of resource.calendar, and never used.
The whole override of resource models should be cleaned but will be done
after migration of resource and stock.calendar.
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).
We are able to create a currency on the fly. A user should not be able to
create a currency when entering master data, currency should only be added
through the currencies menu item and a part of configuration.
To be displayed correctly on odoo app (In a given category and not only in all or hidden)
the module category in the __openerp__.py file should be one of these:
"Accounting",
"Discuss",
"Document Management",
"eCommerce",
"Human Resources",
"Industries",
"Localization",
"Manufacturing",
"Marketing",
"Point of Sale",
"Productivity",
"Project",
"Purchases",
"Sales",
"Warehouse",
"Website",
"Extra Tools",
'Accounting & Finance' will not work, as 'Project Management', ...
Thibault Delavallée