In previous versions, the quantity passed to the bom_explode was the number
of times you needed to count the BoM. If the BoM was for 2 dozens and you pass
48 units, 2 was passed to the bom_explode method. We are now doing the same
for the explode method and we check it is called this way everywhere.
When you produce or consume more than foreseen in a production order,
the system creates extra moves. Before, in case of tracking, it did this without
transferring the stock.move.lots resulting in a wrong stock. That is why now,
when we split moves, we also split the stock.move.lots
For the finished move, it is also important to split between the quantities
of the original procurement and what is extra as the extra might use a push rule e.g.
When updating quantity, it should take use a similar
method as for generating the moves, but with
the quantity already produced (and posted) deduced.
The parameters for these method needed to be changed.
When all the moves are posted,
we should create the necessary extra moves.
If the quantity is put back to the quantity posted, it
might also need to delete moves.
In byproduct, it should take into account the subproduct factor.
When the quantity produced on the work orders has reached the quantity to do,
it should not allow anymore to use the "Done" button on work orders, but
rather use the Finish button instead. With the Update button on the manufacturing order
it is possible to do more.
In v7, it could be in handy that when altering the quantities of a move, it would automatically
update the next chained move as you could change quantities on the fly without any relation
to the original documents.
From v8, this is all being handled by extra moves which might e.g. follow
a different route, so you still know what is related to the original procurement.
But the functionality stayed in the code for who would still need it.
In v10 and in previous versions, manufacturing orders however still use these moves.
When we update the quantity on a halfproduct (which we can do now all the time in v10,
it could change the consumption where it is used in the finished product (in MTO)
That is why it is better to remove this functionality.
(it might also speed up the split method on stock_move)
The propagation of quantities was something from v7, that now causes trouble in mrp for nothing
The default of the date_start on the time records was a
result of the function fields.Datetime.now instead of the function itself
resulting in the start of each blocking time as the start of the server
When changing the quantity being produced on a work order and
serial numbers are consumed, we need to delete or add lines
for every serial number in function of the quantity through the onchange.
We changed the quantity_done to be set to quantity by default (automatically)
as otherwise we forgot to set it. But for the onchange, it means
we need to take it into account otherwise the number of records
would not be diminished.
The labels of the fields say that they store hours, but actually they store minutes. Correct the code to store hours.
Add digits to fload field for a better display in the webclient
date_planned_start should also be Start Deadline instead of Expected Start Date.
We don't want the Expected dates to function as a planning tool, but as
a priority for the planning of the workorders.
This reverts commit dc02f773ce.
This commit caused a side-effect that is worse than the issue
it tried to fix, which was purely cosmetic.
Now in mass-mail mode the template is only rendered once
and all recipients receive the same PDF, which completely
defeats the goal of a dynamic report. We have static
attachments for that.
Original fix related to opw-657152
Reverts PR #10568
the onchange changed the partners of the ticket when the ticket changed project
to the project's partner, but if the ticket already has a partner it shouldn't
change.
! Note forward port: this is a partial backport, ignore when conflict
For some strange reason, the cover_full class was added when the cover
image was changed, without checking if the cover_narrow class was
already there. The cover was then a hybrid cover_narrow cover_full.
The problem was reinforced by the graphene theme which does some
animation on cover_full covers.
rounding field of product_uom now has sql constraint > 0. If set at 0 it rounds
any quantity to 0, which is never a desired result.
Allowing 0 made it so that some users that did not understand the rounding, set
it to 0 and complained that their quantities were messed up.
Also added translations to the error message.
* web_editor, website_blog
Since recent refactoring, web editor dialogs automatically trigger
an event when closed (saved or cancel). The problem is that there
still was manual trigger of those events or variants ("save" instead
of "saved").
To prevent multi-saving and be consistent, all save events are now
automatically triggered on save/close (no more manual) and the event
name is "save".
This fix renames filters in purchase from Invoiced (resp. Not Invoiced)
to Received Bills (resp. Waiting Bills) to be consistent with the states
of the Purchase Orders (i.e. 'Waiting Bills'). The erroneous tooltip of
the Bills Received was also corrected.
In procurement form view display a Purchases stat button that redirects to
the purchase order. It opens the PO form view. Note that Purchase Order field
in Extra Information is left untouched. It is just a shortcut to ease
usability.
Publish buttons appeared in list view item in /shop with commit
5a5dd1e100.
They however never worked for some reasons:
* The publish buttons were unclickable as the around style was badly
implemented: the section title was over the publish button
* Even if it was clickable, the publish button handler had no prevent
default, thus it submitted the form it is in -> crash when no cart
button or added to cart on click on publish button if there was a cart
button...
Note: the style should be reviewed in next versions, this commit, as
a 9.0 fix, fixes the style with the minimum code and so that it does
not break any theme.
This reverts commit 7e6ad941cf.
The domain makes clear that the location to be chosen in is among the children of the location zones chosen in the picking. That way, if the stock would be calculated in the past (e.g. also for the stock valuation report), the system is going to think it is maybe still internal, while it went out, ..., so those domains are crucial.
It is already defined as a payment method (subtype=inbound) and that's what we want. No need of adding 'electronic' in 'payment_type' selection (that crashes if we select that, btw) and 'payment_method_id_code' is a duplicate of 'payment_method_code'.
'Project > Reports' menu show 'Tasks Analysis'. But
if you install project_issue, or rating_project, some
children menus are added, making 'Tasks Analysis'
invisible.
Trying here to set the same order for issues, ratings,
forecast as in other menus, labels and kanban card.
When you create a leave, you first set the start date. The date widget triggers
and automatically sets you at today, which triggers the onchange and puts the
end date at today + 8 hours. You then set your start date in the future
-> invalid dates because start date > end date.
This commit removes the onchange verification of the dates, because almost
everyone gets the above problem and because it is redundant with the sql
constraint that triggers anyway when you try to save with invalid dates.
a random ensure_one() was added during the migration causing an error when
modifying portal access management for partners with more than one contact.
Removing it.
That bug was introduced when removing the invoice workflow, where a call to action_invoice_cancel() has been used instead of action_invoice_reopen() which does slightly different things, as you can imagine.
This fix prevents from giving the reason of the refund to the draft invoice created if you select the 'modify' option when refunding an invoice, which now keeps the description of the original invoice.
Josse Colpaert