When the PO is related to a contact of a company, the current behavior
is to add the contact in the list of suppliers of the product. However,
there is little chance that this is actually the desired behavior.
Indeed, in most of the cases, this will simply add a lot of useless
suppliers on a product.
The fix is to add the parent company of the contact in the list of
vendors, since `_select_seller` wil also search in the parent companies
to get a purchase price.
opw-672862
The price unit on the account move line is defined as a monetary field.
However, on a Sales Order or on a Purchase Order, the price unit is
defined as a float with precision 'Product Price'. Therefore, when an
invoice is generated from a SO or a PO, inconsistencies arise if the
product price precision is larger than the currency precision.
opw-673251
When a product is set up to generate a purchase tender instead of a
purchase order, the associated procurement is set in exception.
This is because the result of `make_po` is returned by the method `_run`,
and the result of `_run` is used to determine if the procurement is
running or in exception. Since a purchase tender does not generate the PO,
the method `make_po` returns an empty list, and therefore the procurement
is considered as in exception.
The fix is to return the procurement_id instead if a purchase order or a
purchase tender has been created.
opw-672170
Currently there is a selection field 'account_type' on the
account.analytic.account model with 2 values : Active or Archived
Let's use an active field instead and add a Archive stat button on the
form. That way, we can remove all the domain ('account_type','=','normal')
which are implicit with the generic active field behavior
Otherwise, when uninstalling the `purchase` module, this
menu is not deleted, while it should.
Besides, there is no reason to set `base.` to this xml_id:
It's not used by any other module.
opw-672130
The type of the related field purchase_id is many2one.
With the type the function _related_read in fields.py can convert
the record "purchase.order" in id.
On the product_template, the stat button to indicate the purchased quatity
is buggy in several ways.
1/ The states in the read_group domain have been mistaken with the states
on the picking (clap, clap)
2/ The read_group is seeking the fields product_id and quantity. Too bad, on
the model the name is unit_quantity (clap, clap)
3/ The displayed PO lines weren't chosen from a domain. So the computed quantity
didn't correspond to the displayed lines from the button (small clap, clap)
4/ The action_purchase_line_product_tree linked to the stat button is selecting
the PO lines where the product is the product id. Too bad, on the PO line
this is a product.product and on the current object this is a product.template
(epic clap, clap)
When a "Drop Shipping" route is used on a product, the origin document
is duplicated on the PO created. This is because in this case,
po_rec.origin and procurement.origin are the same.
opw-671039
This additional administration group was formerly used to hide
the configuration menuitems for the common users.
Being manager should be enough to access these items
Yannick Tivisse