When deacreasing a quantity on a PO it will decrease the quantity
of an associated move. When the move's quantity reach 0, previously the
move was unlinked and aslo the picking if all moves inside were unlinked.
However the destination move(s) still exist with the quantity that has been
removed in the original move. It can confuse the end user which have a move without
origin.
This commit cancel the move/picking instead of unlink them. Thanks to this
the end user still have the link with the original moves and can guess from where
their destinations moves come from. It also remove the filter on PO in order
to display the canceled picking.
Use case to reproduce the bug:
- Create a PO line with 10 product -> validate the picking
- Edit the PO line and add 10 product -> it creates a new picking with a move line
- Edit the PO line and remove the 10 products
-> There still an empty picking that is not linked to the PO.
This happens because the _create_or_update_picking in purchase
only remove the stock move if it is empty but do not check anything
on the picking.
This commit add a check on the picking if there is no move inside,
delete it.
Use case to reproduce the bug:
One procurement is running for a PO. Cancel one move in the picking and
create it again. Pass the picking in done.
--> The procurement stay in running state
It happens because the check method of procurement look if all moves linked
are in done state but in this case, there is one move in cancel and one
move in done.
This commit check instead if all move are in cancel or done and at
least one is in done state.
opw-753177
In Python 3 round:
* rounds half to even (banker's rounding) rather than up
* returns an int if not given a precision (or given a precision of
None)
* discards the negative sign when rounding to 0
Add a compatibility shim which implements P2 behaviour and at least
allows passing float_utils's tests.
Implementing float_round on top of Decimal was attempted but did not
work: although Decimal.quantize takes a non-integral
Decimal (e.g. ``d.quantize(D('0.001'))``) it only supports integral
powers of 10 and does not support quantizing to e.g. 0.05: while that
will not fail it will just use the exponent for quantization and 0.05
is thus equivalent to 0.01, which is not what we want if e.g. need to
round a value to 5 cents.
This is hinted at but maybe not clearly spelled out by the official
documentation:
> Return a value equal to the first operand after rounding
> and **having the exponent of** the second operand.
Also convert a bunch of hand-rolled currency rounding to just using
the round() method on res.currency.
The new implementation of stock moves the cost of products from quants to
moves. So we have implemented the FIFO and average cost method based on
those moves instead of using quants.
- When average price is choosed, a field average_price is set on the
product.
- The tests have been completed with an example of how fifo work with
negative stock.
As the use of real price method is really rare, because of the rigor
required on traceability for such method, we removed this functionnality.
- The tests purchase/test/fifo_price.yml have been adapted to use the
FIFO costing method instead of real price.
The old report stock history doesn't exist anymore, and is replaced by
the move view that contains all the cost information.
The methods `get_price_unit` have been moved from the stock to
stock_account.
The methods `_set_default_price_moves` and
`set_default_price_unit_from_product` have been removed from stock.
Explaination of FIFO and average:
- In action_done for an out move in average and fifo, the price_unit and
stock_value are updated.
- For FIFO, it will use the qty_remaining on the in moves to check from
which in moves to take the stock values for the out.
- In case of negative stock in FIFO, it puts also qty_remaining on OUTs.
- In the case of average, it will take the cumulated value of the last
move and divide it by the quantity in stock.
This commit is pretty much a 'work in progress':
- Edit 'done' moves when the costing method is FIFO doesn't trigger the
replay the FIFO stack.
- The landed_costs feature doesn't work.
This commit adapt purchase to be able to edit purchase line ordered quantity
and propagate it to the related picking after the request for quotation
validation.
These are the supported use case
- When you increase the quantity on a purchase line, an extra move (and
an extra picking if they are all done or canceled) is created with the
difference between old and new value and the push rules are applied on
it.
- When you decrease the quantity of a purchase line, different behaviors
can occurs:
* If you plan to decrese the ordered quantity under the received
quantity, you get a user error saying tht you have to make some
return before.
* Else the moves not done or cancelled are decreased by starting with
move having no procurement_id. The decrease is not propagated
through push or pull rules.
* If you decreased the quantity under the invoiced quantity, a next
activity is created to remind you to do a refund.
If two MOs are using the same PO, when we cancel the first MO, the
check availability of second MO is not working.
The incoming shipment of the Purchase Order has the first MO's move_id
as the destination move. When we cancel the first MO, the incoming
shipment of Purchase Order still holds the first MO's move. Because of
that reason, the check availability is not working for the second MO.
While setting the destination move for the stock moves of the incoming
shipment, it should ignore the cancelled procurements.
Closes#17701
opw-748074
Courtesy of @suganthikarunanithi
In version 8.0, there was a stored field `minimum_planned_date`.
In version 9.0, this field was renamed `date_planned` and loose it
store attribute.
In version 10.0. the field is stored again.
Keeping this `oldname` attribute will lead to reuse old data from
version 8.0 when migrating the database to version 10.0.
Closes#17631
opw-744097
Currently, all the methods that start with `get_default_` and `set_` are called on a res.config.settings loading or saving.
This commit purpose is to replace all the occurences of `get_default_foo` and `set_foo`. As these methods won't be called anymore, a warning is logged to notice its deprecation.
The generic method `get_default_fields` and `set_fields` could be improved too. The method names and API are not so good:
Why "default" fields? What you ask for is the current value of the stuff, shown as fields in the model. The values are fed as default values in the wizard, but that's an implementation trick.
Why "fields"? What you ask for are configuration parameters, and such things.
Why passing a list of fields? Its value is never used.
We should further simplify the API of both methods to something like
def get_values(self):
return {}
def set_values(self):
pass
Method `get_default_fields`
===========================
Currently all the methods beginning by `get_default` are used to fetch their default values, usually by looking in the ir.config_parameter table.
As several methods `get_default_fields` have been defined in res_config classes, it better to define it in base and calling to super to avoid side effects like the following example
- 2 classes that override the same class and define the same method. In that case one method will never be called, as it is ovewritten by the other.
Method `set_fields`
===================
Currently all the methods beginning by `set_` are used to set their values, usually in the ir.config_parameter table.
As several methods `set_fields` have been defined in res_config classes, it better to define it in base and calling to super to avoid side effects like the following example
- 2 classes that override the same class and define the same method. In that case one method will never be called, as it is ovewritten by the other.
Methods `get_default_foo` and `set_foo`
=======================================
This commit deprecates the method starting with `get_default_` or `set_` in the res.config models. A warning is raised in that case.
Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
Also, reset po_lead when use_po_lead is unchecked to avoid it to be used it further computations.
PURPOSE
=======
The status "Bills received" on the PO simply means that there are no bills to receive for now, not that you have really received bills. This is confusing for users.
SPECIFICATION
=============
Replace the invoice status string on PO "Bills received" by "No Bill to Receive"
When creating a vendor bill from a PO, the payment term configured in
the PO was lost due to function _onchange_partner_id.
When creating a vendor bill, the field payment term was invisibile if
there was no payment term set on the vendor.
opw:744714
Thibault Delavallée