Comment 20 for bug 1160365

On 03/28/2013 07:01 AM, Raphaël Valyi - http://www.akretion.com wrote:
 > I started coding a patch adding a contact_id at least in the account
 > module, but not finished yet sorry.

In your solution, have you decided on a way to make the contact info available
in all search views, reports, etc? Because if the contact automatically carries
the company info, the opposite is not true. So if your strategy is to force the
`partner_id` field to contain the "commercial party" of the contact, and add a
second `contact_id` field to store the contact, the rest of the system will
still be using `partner_id`. So the contact chosen by the user will disappear
everywhere else. Won't that be rather confusing for the user and make the
contact_id a useless field, defeating the whole purpose of the 7.0 model?

 > Meanwhile, here are some more quick examples of things that won't work
> as claimed if you keep enabling contacts in partner_id on business
> documents:
>
> Sale module: sale/sale_view.xml: <field
> name="project_id" context="{'partner_id':partner_id,
> 'default_pricelist_id':pricelist_id, 'default_name':name, 'default_type':
> 'contract'}" groups="sale.group_analytic_accounting"
>
> So basically this context will automatically create the analytic account
> (yah project_id is an analytic account ;-) according to the partner_id of
> the sale order. That is, you will now create as many analytic accounts as
> contacts for the same customer on v7. Very smart...

This looks like a bug that already existed in previous versions of OpenERP: the
context should probably be corrected to: `'default_partner_id':
partner_invoice_id`, so the analytic account is properly created for the
invoicing partner: either the one you manually choose or the one automatically
chosen by the system based on the partner `type`, as described in Part C.

> purchase/stock_view.xml: <field name="purchase_id"
> domain="[('invoice_method','=','picking')]"
> context="{'search_default_partner_id':partner_id,'default_partner_id':partner_id,
> 'default_invoice_method':'picking'}"/>
>
> Here it allows to create an incoming shipment and link it to some existing
> purchase order with some default filtering. But now, with v7 contact
> "innovation", you may totally miss purchase orders related to the right
> supplier but related to a different contact. You may also fail to look at
> the parent_id if you selected a contact in the picking instead...

That seems the expected behavior when you manually create an incoming shipment
and choose a supplier contact as the Supplier. First, the system will allow you
to link it to a PO from any partner because the domain does not restrict it -
and auto-completion will work. Secondly: if you open the full search view or
try to create a PO on-the-fly the system will simply copy the selected Supplier
in the Supplier field, as expected. You can change it if you want but if you
selected a contact as Supplier it's probably because you meant it - a question
of granularity.
And as a reminder, the system is taking care of creating the appropriate
incoming shipments when you create a purchase order, so these cases should be
exceptions.

It's really a question of granularity: in 7.0 a contact is now considered a
valid representative entity for her company. However there's no reason to
believe that users will be forced to use contacts when they don't want to.

If I am talking to Sylvie Lelitre from Agrolait on the phone and I create a SO
for her, it is natural that I will choose her as Customer. And the Invoicing
Partner will be automatically set to "Agrolait" because Sylvie is a contact
with type "contact", not "invoicing" (part C of the solution). So the invoice
will be created for "Agrolait". And I will be interested to see "Sylvie Lelitre
(Agrolait)" as a first-class entry in the Sales Orders reporting, while the
accounting department will only care about seeing "Agrolait" as a whole in the
Invoice Analysis report.
On the other hand if I always receive generic orders for "Agrolait", I will
naturally use "Agrolait" as the SO Customer, and will only care about seeing
only "Agrolait" in the reporting everywhere.