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
After discussing with jco, we decided to keep it simple and have a coherent behavior between different versions, we then changed the behavior from the one of jbefficient PR at 92adf673f7.
Choosing a currency different than the purchase order pricelist is allowed.
Therefore, the purchase order report must display the currency
of the purchase order, and not the currency of the pricelist.
opw:628767
Fixes#5443
The name must be changed when changing of product,
but not for other changes, quantity for instance.
The 'or not uom_id' is just for retro-compatibility concerns
uom_id being False actually means we just changed of product,
and the name must therefore be changed
name as been set as False in the onchange call in the view
for the product_id field, in this rev.,
so the name being False now means th change of product
Nevertheless, existing databases for which the view
is not up to date won't have this change
and we therefore have to rely on something else to know
when the product has been changed or not.
fixes#5295
opw-628138
The seller_id field is a related that is read administrator so it would fetch
the first line, whatever the company specified.
Setting related_sudo=False would not be enough as creating purchase orders
through the scheduler makes the computation done as administrator.
Use the company of the procurement (required) to search for a supplier.
If no result, fallback on the first one as before.
Fixes#3833, opw 618809
This rev. is related to 8381d47543
The action action_purchase_line_product_tree is used in both
product templates and product variants forms.
Therefore, the default_product_id: active_id in the context
cannot be used,
As sometimes it will active_id will be a product template,
sometimes it will be a product variant.
I believe two different window actions should be used,
instead of sharing a common one and making hacks.
Nevertheless, as we avoid taking risks in stable releases
This should be done in master.
The purchases button on product templates open the purchase orders
that have at least one of the variants of the templates
Set in the context of the action button action_purchase_line_product_tree
'search_default_product_id': active_id, 'default_product_id': active_id
as no point, as default_product_id expects a variant id (product.product)
while active_id is a template id (product.template).
opw-626521
Debian does not allow fetching data from external website at runtime.
This fixes the privacy-breach-generic lintian warnings for Debian packaging.
The removed youtube url was a dead link...
Goffin Simon
Olivier Dony
Denis Ledoux
Christophe Simonis
Nicolas Martinelli
Martin Trigaux
Adil Houmadi
moylop260
Josse Colpaert
David Monjoie
jbeficent
Alexandre Fayolle
Adrien Peiffer (ACSONE)
Goffin Simon
Aaron Bohy