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.