Access on purchase order lines for managers is present twice in the
security file. Once with only read access and once with full access.
I suppose the latter one is the correct one.
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.
Purpose
=======
Issue: Product_id field should be visible only when product has more than one variant
Here's how it can be reproduced,
Assign user with group group_product_variant
Create a product without any variant
In this case, the product_id field won't be shown in product.template's internal form view for product.supplierinfo, that's working fine. But, now, as this fix is reverted, the product_id field will be visible in product.template's internal tree view for product.supplierinfo.
- Show Product(product.supplierinfo) field when product has more than one variants.
- Improve tooltip on Product(product.supplierinfo) and 'Cost'(product.template) fields.
- Hide 'Cost'(product.template) field when product has more than one variant
Purpose
=======
1. There is some confusion between the vendor price and the cost price of a product. The goal of this task is to clarify it for users.
2. Some users would like to set up vendor prices specific to a variant, the goal of this task is to allow them to do that.
Specification
=============
- Add a clear tooltip on the Cost field (standard_price) : "The cost price is used to valuate your inventory."
- When creating variants, it is impossible to set the cost of the product variant, it always resets to 0. It should be hidden if the product has some variants
- Add product_id o2m in vendors form, tree view on product template, and same field should be displayed on variant form view (the field is not required)
- Product_id field visible only when product has more than one variant
- Add a tooltip on this field : "If not set, the vendor price will apply to all variants of this products."
- Vendor price calculation for automated generated RFQ (should be based on sequence: take the first vendor price that matches all the conditions)
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.
To reproduce:
- Go Website Admin > Configuration > Settings
- Change the Website Name
- Click on 'Cancel'
The name is saved.
When the "Cancel" button is clicked, we automatically save the record
(which is a transient model). Since the field is a related to the
company, the name is changed even if we canceled.
opw-760749
When "No message" is set on field purchase_line_warn/sale_line_warn,
the message doesn't have to be displayed in the respective field
purchase_line_warn_msg/sale_line_warn_msg.
opw:760801
Fine tuning of this commit:7333f5e
When the PO lines were not ordered according to the scheduled date,
the scheduled date of the picking was wrong when delivering.
opw:752192
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
This fix previous commit a29f7f671b.
(1) Some objects have no color field.
(2) There was an issue when two many2many tags were instantiated:
If the first one had the 'color_field' attribute the second one
had it too even if this attribute weren't specified.
Now, it's fixed in data_manager
Steps to reproduce:
-Create a PO with two lines L1 and L2
-L1 has product P with qty=10 for a scheduled date=23/07/2017
-L2 has product P with qty=10 for a scheduled date=30/07/2017
-Confirm the PO
When delivering 5P of L1, the scheduled date of the picking is the
right date which is 23/07/2017
But when delivering the other 5P of L1, the scheduled date of the
second picking was 30/07/2017 instead of 23/07/2017.
opw:752192
Thibault Delavallée