Comment 2 for bug 1160365


thanks for the good summary of the issue and the way you see a solution today.
Now sorry this is still unclear to me, and I'm still worried you try to fix it the wrong way.

So are you YES or NO actually going to add new contact_id fields on business documents? (like we were referring as the B) solution in the original bug) ?

You says "A) Let the "commercial party" for a partner be the person or company that is used as reference for all invoicing/accounting matters"
Is that supposed to be the existing partner_id field or a new field (stored or not) ?

Because if that "commercial party" is the regular existing partner_id then we agree on the solution. Else I claim you are still getting it wrong...

Again not clear for me when you say:
"C) When a contact/address is selected as the reference for a business document (SO/PO),"
So do have that additional contact_id field (as we are advocating since the beginning) setting that proper "commercial entity" with the logic you described on the existing partner_id field or is that some kind of blind faith you would solve it differently?

Now, may be you still plan to allow selecting the contact in partner_id and may be we still not agree.
I'm specially worried when you write:
"2) Any code in business modules that deals with invoicing/accounting related data should automatically use the data of the "commercial party", thanks to B, because the data should always be in sync."

How that Olivier?
Look at the following piece of code in the account/ file (there are dozens of such cases if not hundreds considering also the sale, purchase, stock and main community modules):

pay_pro_id =,uid,[('name','=','property_account_payable'),('res_id','=','res.partner,'+str(partner_id)+''),('company_id','=',company_id)])

You can make a contact inherit whatever you want form its parent company: if partner_id is suddenly allowed to be just the id of the contact record, that property search will fail to find the property attached to the company record one.
But this is just a quick example: any search/domain involving partner_id will not work out of the box at all and lead to regressions very hard to spot.

Also, I strongly advocate for keeping partner_id the same id between business documents such as invoices, sale and purchase orders. Because else you would really make analysis over complicated for no benefit at all. Imagine also all the action_window showing related invoices, orders, payments all based on partner_id. All this has to keep working with no regression!

So when I read "We think the solution should be mostly handled by the res.partner model itself". Well if you don't add these contact_id fields on business documents (as it was your plan until now apparently) I fear you are lying to yourself or to your community.

So sorry, this is not clear to me yet. You say "contact/address" is the right level of modularity. Well, I agree and if you add that contact_id field on business documents, you will still be able to perform any analysis at the contact level if you want to. So no detail would be lost.

Also, I would like to insist that reading accounting/financial/fiscal data isn't limited to the account module.
For instance, in many situations (specially sales bewteen sovereign states such as international commerce or inside federal countries), you may need to read fiscal data right from the sale order to find out the right taxes to display.
So for instance if partner_id can be a contact in a sale order or a purchase order, well all the fiscal-rule framework (a pillar for our localization but also used in international e-commerce) is broken

But of course, that was just an example. if partner_id can be a contact, regressions are to be counted by hundreds.

So could you be more specific, will that "commercial entity" be the regular partner_id field provided you add an extra contact_id field? Or are you still trying to make it work with partner_id being a company contact eventually?

Thank you for looking at that important problem.