The fact is that you gave the example of the invoice. The invoice has been modified in the merge proposal to only accept invoice-able partners.
So, a priori, you don't mix partners and contacts (or addresses).
An example of issue by mixing partners and contacts / addresses.
I will not use a company for the example, but an individual customer.
The customer is Joël Grand-Guillaume (id: 5), the address on this record is his home address.
He has a second address registered, at work, because he want to be delivery there (id: 6).
He phones because he want to address a complaint.
A claim is created on Joël Grand-Guillaume.
He phones again for another claim.
The user selects the wrong entry, he choose the work address instead of the main one.
We have 2 claims, one time the partner_id is a partner and the second time it is an address.
If you open the Joël Grand-Guillaume's main view, and display the 'History' tab, you should see the full list of claims of Joël.
But you won't see the second one, the second claim is displayed on his work address. (Same history if we group by partner)
Technically correct, but not what a user would like.
By cons, if we name the field displayed to the user 'contact_id' (we'll have id 6), and we automatically fill the 'partner_id' with the id 5, we can group by partner_id and link the partner to all his claims in the history tab using partner_id.
The fact is that you gave the example of the invoice. The invoice has been modified in the merge proposal to only accept invoice-able partners.
So, a priori, you don't mix partners and contacts (or addresses).
An example of issue by mixing partners and contacts / addresses.
I will not use a company for the example, but an individual customer.
The customer is Joël Grand-Guillaume (id: 5), the address on this record is his home address.
He has a second address registered, at work, because he want to be delivery there (id: 6).
He phones because he want to address a complaint.
A claim is created on Joël Grand-Guillaume.
He phones again for another claim.
The user selects the wrong entry, he choose the work address instead of the main one.
We have 2 claims, one time the partner_id is a partner and the second time it is an address.
If you open the Joël Grand-Guillaume's main view, and display the 'History' tab, you should see the full list of claims of Joël.
But you won't see the second one, the second claim is displayed on his work address. (Same history if we group by partner)
Technically correct, but not what a user would like.
By cons, if we name the field displayed to the user 'contact_id' (we'll have id 6), and we automatically fill the 'partner_id' with the id 5, we can group by partner_id and link the partner to all his claims in the history tab using partner_id.