When we return goods and a refund is created, we check the purchase order
linked to the original move. Therefore, the appropriate currency and unit
prices will be chosen.
opw-643085
Returning `picking_id` can be useful for overrides.
In addition, when there is no return statement,
the method basically returns None.
As this is a public method (not beginning with '_'), it can
be called with an xmlrpc call, and `None` is not an
accepted return value for the xmlrpc protocol.
Closes#1714
During tests, some creation of user records would unnecessarily trigger
password reset or set a password, both of which would trigger password
hashing which takes some time (for good reasons).
Fix by:
* passing no_reset_password in YAML tests and some Python tests still
missing it (a number of Python tests already used it)
* removing passwords from YAML records as they're never necessary, the
test user records are not expected to ever log in
Fixes the impossibility to invoice purchase order lines, which were never
invoiced but set to invoiced by validating a first invoice created by invoice
control "manual".
When a PO line is deleted, it sets the related procurements in exception.
This fix logs this action in the procurement chatter, for WMS administration
and maintenance purposes.
In case of a partial delivery of the products to receive, the procurement is
not considered as done since procurement.purchase_line_id.order_id.shipped is
false.
opw-641503
If the state of the PO is 'approved', there is no transition foreseen in
order to cancel the PO.
The user might be blocked in the following situation:
- Create a purchase order with invoicing set as Based on incoming shipment
- Validate the purchase order, create the shipment
- Then, cancel it (the shipment)
- Return back in the purchase order, the PO should be in shipping exception
- Hit the "manually corrected"
- Then, try to cancel the PO: nothing happens.
opw-641014
Canceled lines must be excluded from most of the operations done on a purchases orders.
The check has been done in some places but some of the loops on the order lines do not do it.
This commit correct them.
If an extra move contains a product which is not initially in the order,
the taxes set on this product must be considered according to the fiscal position
of this order.
opw:634305
This is related to revision 65d7cc524d
The `order_line` field of `purchase.order` is readonly within states
aprroved, done. See the field definition. This means it should be
possible to remove lines of a `purchase.order` when the PO is in
any other state than approved or done.
Therefore, the deletion of lines shouldn't be prevented
when the PO is not in state approved or done
opw-634538
If the whole view relates to a specific group,
apply the group on the view itself instead of
each view part (each fields, each page, each div,...),
so the view is loaded / added to the base view
only if the user is in the right group.
So the view is not loaded uselessly
and the fields are not read for nothing
(performances & security).
Indeed, when a group is applied on a field itself, the field content
is read, but hidden, therefore reading the content of the field
uselessly, and potentially leading to accesses issues
if the user hasn't the rights to read the field.
(e.g. reading a property when not having access to the model
of the proprty, pricelists on partners for instance)
opw-634402
Update:
When an existing purchase order line is updated, for example if a new procurement was required,
we check if the sum of existing running linked procurements is larger than the quantity in the
purchase order. If it is the case, we update the quantity and the unit price accordingly.
Without this fix, we systematically add the procurement quantity (or the provider minimum quantity)
to the purchase order line, even if the sum of the procurements is smaller than the ordered
quantity.
Cancel:
When a procurement is cancelled, we recompute the unit price of the associated purchase order
according to the quantity and make sure the provider minimum quantity is met. If the required
quantity is zero, we cancel and unlink the purchase order line.
opw: 632175 and 632176
Make sure the purchase order is marked as invoiced only when fully invoiced.
If the invoices are generated on delivery order (invoice_method picking), make
sure all products are delivered before setting it as invoiced.
opw 614256
Fix stock warehouse column on purchase report,
we need to join stock_picking_type and stock_warehouse
in order to have the warehouse itself
Closes#6409
When creating a pickign from a purchase order, do not use the schedule date
('date_planned') to specify the creation date ('date') of a picking.
There is already field called Scheduled Date ('min_date') and Max Expected Date
('max_date') that can display this information, this is redundand.
Fixes#4352
If a purchase order is created with free goods (e.g. 5 units offered if 100 are purchased),
the price_unit of stock.move and the cost of stock.quant were set to the product cost price
instead of zero. This would lead to inconsistencies in the 'Current Inventory Valuation'.
opw: 630593