Currently timezones were not or incorrectly taken into account in resource
computation. Indeed complexity comes from attendances being expressed in
naive timezones valid for all users, whereas dates and leaves are computed
into UTC. Computation should always be done in user timezone so that there
are no overlapping days and all time intervals are correctly computed.
A new timezone field is added on leaves to know in which timezone they
were originally encoded. Indeed putting them in naive user timezone
require its original timezone, not the current user timezone, as those
can be different.
This commit also contains code cleaning in resource to be a bit more
pythonic, simplify method parameters and offer a more simple api to
other modules.
Eventually code field is removed on resource as it is not really necessary
for resources. It is explicitly added on workcenter model who use it.
Old methods are still present since a long time and are deprecated since
saas-3. This compatibility layer adds unnecessary complexity to the module
API. Those methods should now be removed. Some renaming is also performed
to ease resource api understanding, notably to better differentiate
internal methods from other methods.
All addons are updated accordingly.
As picking types aren't always used in a picking context, and picking
aren't really meanigful for a lot of people, we rename this concept as
"operation type" in views and in the planner.
To reproduce:
- Create a product A with the routes Manufacturing & Make to Order
- Create a product B with the routes Make to Order & a custom one "Move
from Shelf 1" (see screenshot for the configuration detail)
- Create a BoM for product A which contains the component product B
- Sell product A in a SO and confirm it
- It creates a delivery order for product A, a manufacturing order for
Product A & B and an internal transfer for product B
- The move for product B from WH/Stock/Shelf 1 to WH/Stock is indeed
linked to the move for product B from WH/Stock to Virtual Location/Production
- Cancel the sales order
- All stock moves are cancelled, except the one related to the internal
transfer (WH/Stock/Shelf 1 to WH/Stock)
When the manufacturing order is canceled, raw material as well as
finished moves are canceled. All procurements with finished moves as
"Destination Move" are canceled as well. However, in this use case, a
procurement has been created for a raw material.
The solution is to cancel procurements for raw materials as well, so it
cancels the internal transfer.
opw-706100
In a MO, change a product in "Consumed Materials" by clicking on "Search
more...". It crashes.
Clicking on "Search more..." triggers the onchange since it empties the
line. Since there is no product on the line anymore, it crashes.
opw-705644
The field `quantity_available` can be computed in two different ways:
- equal to `product_uom_qty`
- equal to `reserved_availability`
However, `product_uom_qty` is in the UoM of the move, while
`reserved_availability` is in the UoM of the product.
We convert into the UoM of the move, because `quantity_available` is
supposed to be in the same UoM than `product_uom_qty` ("To Consume").
opw-704775
We store quantity available to avoid numerical inconsistencies. For
exemple, with a rounding of 1e-6:
- `product_uom_qty` = 0.058824 (stored)
- `quantity_available` = 0.058823999999994 (not stored)
The dependencies of the field are fixed from v10.0.
opw-704775
Before, when you would put a quantity in a BoM line that was not rounded
to its UoM (e.g. use 0.3 piece with rounding 1.0) it would not round this
quantity in the MO also (when exploding the BoM), and the user could also
enter a not rounded quantity himself for the quantity produced or
consumed.
The moves were split with the exact quantities, but the moves were validated
taking into account rounded quantities. This resulted in either moving 2
pieces instead of 1 (entering 0.7 or 1 piece) or raising an error telling
you can not process moves with 0 quantity (0.3 piece).
As product_efficiency and product_rounding was removed from the BoM/BoM
line in v10, if the rounding is correctly handled, the feature could work
like in v9, by e.g. putting 1.03 in the bom line (97% efficiency) and
rounding up when exploding the BoM (e.g. producing 10 pieces would put
it to 11).
When "producing", we round the produced qty to the product uom (it does
not make sense to produce 1.32 if your uom rounding is 1.0). The user
might now change the produced quantity, that's why we round-up when
validating the move: indeed, if the user slightly increase the produced
value (below the uom unit), it actually means he produced more.
This way, instead of not rounding anything and doing rounding behind the
scenes, leading to errors, we round everything and the user sees the
result directly.
When posting inventory during a manufacturing order,
all raw material and finished product moves are used,
also those done from a previous post inventory.
This is no problem for the moving of quants because
a filtering is done in the move_validate method,
but it is a problem for the price calculation in
mrp_account and for linking the consumed/produced_quant_ids
of the quants of the raw and finished moves.
Before this fix, it would calculate already consumed materials
a second time in the price of the finished products and would
link quants produced with previously consumed quants (and vice versa)
when doing a second post inventory.
We add a test to show the issue.
When clicking on the "manufacturing" vignette in the inventory
dashboard, the records were not filtered correctly (example: add a new
warehouse, a new "manufacturing" vignette appears for this warehouse in
the inventory dashboard, clicking on it would display the MO of all the
warehouses).
With this fix, as with the pickings, it will only show the count of MO
filtered to that specific picking type in the vignette, and clicking on
it will displayed the filtered ones.
We implementent the method of the compute field the same way the similar
method for the picking is implemented.
fixes#15008
According to the routes set on the products of the raw materials, a
procurement may have to be created for the consumed lines of the MO.
A route may also be set on a product category. Before this patch, we
only look for procurement rules for the routes defined on the products
and on its category, ignoring the inherited route of the parent category.
Fortunetaly, we have a computed field on the product model returning
all the routes from the current category, so we use this one in the
search for procurement rules.
A test has been added to show the failure.
Before, when the routing of a production order was empty (no operations),
it got into an inconsistent state (you click on "plan" and nothing happens).
Empty routings were used before to do subcontracting or 2-steps inventeory
(we did not set any operations on the routing but we set a location).
Here, we change the related routing field on the production order into a
calculated field which becomes empty when the routing has no operations.
This way, the "produce" button is displayed (as for production orders
without routing) and working/
This is a temporary patch to workaround the issuein a stable release.
In master, we might remove the location on routing and place it on the
workcenters and put a constraint that does not allow an empty routing.
Before this patch, the inventory was automatically posted when you click
on "done" on the last planned work order. This behavior was preventing
the user from correcting, for example, the consumed quantity on the raw
materials move on the manufacturing order if it was different from the
theoretical quantity. Note that finishing anyone but the last work order
still let you edit the consumed quantity. Same with changing the lot.
Now you have to click on "mark as done" on the manufacturing order to
post the inventory. Note that this is the same behavior when working
without work order (produce > mark as done will post).
We adapt the tests to reflect this change.
The issue is that if you block a workorder when you exceeded the
expected time, the workcenter is not blocked.
The workcenter state is computed according to its productivity lines.
The productivy lines are marked with a loss type type that define the
reason of the time loss (availability problem like missing equipment or
quality problem like broken equipment). There are also two magic loss
type that define if the work on the workcenter is done in the expected
time (fully productive time) or is done exceeding the expected time
(reduced speed). The unblock button appears if the workcenter is
blocked.
To compute the workcenter state, we have to look through the last
productivity line of the workcenter having no end_date. Before the
patch, we look for the last productivity line and it could return one
with an end_date while there was a productivity line without one and it
was this one that would define the workcenter state.
This is solved by immediately searching for a record without end date.
We also add some comment to the code to understand a little more what's
going on.
A manufacturing manager can unbuild an order without being an inventory manager.
The action unbuild only appears when the user is manufacturing manager.
opw:695734
The start date of a manufacturing order is never set. One consequence is
that the Gantt view, which relies on this field, is never populated.
opw-693743
ir.needaction_mixin is not used anymore by the webclient.
From 9.0, the concept has changed: this feature is now
available in mail module, with the mail.thread mixin,
and message_neeadction field.
Remove all code handeling needaction bullet and
counter on ir.ui.menu, knowing that since 9.0
webclient does not display the counter anymore.
This code was, thus, useless and some RPC calls
were done for nothing, and adapt accounting
reconcialiation widget.
When there are 3 different lots reserved for 3 different serial
numbers for the final product, if you do the first finished product, the
finished lot is put on all stock.move.lots even if nothing has been
consumed for it.
This results in traceability report for the first finished lot being linked
to all of lots instead of just the one that was consumed.
Now we update lot_produced_id only on stock.move.lots where quantity_done > 0.
That way it will only links with the correct one.
Set sale order and production order link on Mo. override make_mo method in sale_mrp module to set sale order reference in mo.
.and to find final destination move, i created one common private method to get parent move.
MESSAGES TO DISPLAY:
-Set a Reordering Rule (stock.warehouse.orderpoint) that creates a manufacturing order:
"This manufacturing order has been created from: OP/00001"
-Create new Sales order of manufactured product , there will be a Source Document with procurement of that Sale Order
"This manufacturing order has been created from: SO001"
-create MO for BoM items of the product, there will be a Source Document with procurement of that Manufacturing Order
"This manufacturing order has been created from: MO/00001"
Before, when we consumed 3 instead of 1 in a production order, it
gave a traceback. It was because it created moves
with negative quantities. So, something was wrong with
the quantity_done/product_uom_qty set when creating the extra moves
When creating an extra move because of the procurement,
but you still need to split afterwards (e.g. procurement 10, production order 12, you do 11),
then you should have a difference between quantity_done and product_uom_qty
in the extra move and not try to change it on the original.
That way, we make sure we pass the correct quantities.
Christophe Simonis