Comment 18 for bug 1160365

We discussed this question at Therp and find to favor the two fields (of type many2one: res.partner) approach. The second field should be non-mandatory but take precedence over the first one (partner_id) if set.

The reasoning is threefold:

This datamodel reflects what you actually want to have. Business documents simply have a relation to two entities: The company a contact/address belong to and the contact itself. Sometimes they happen to be identical, sometimes not, which is not a problem with the two fields approach. Of course, you would implement some smart on_change methods that choose the most likely subpartner or the matching company. You may even hide the second field per default. But those UI considerations don't really matter for advocating the two field approach.

Then also this approach seems to be a lot less intrusive code-wise. Apart from the code Olivier proposes to write, modules dealing with partner_ids have to be adopted to the fact that you're not sure which kind of entity sits in your partner_id. Additionally to _find_commercial_party, you'll also have to provide _find_legal_person and _find_natural person, which the modules have to use.

More important: users should be prevented from entering data like fiscal position, payment terms etc on the partner that is not the legal customer. The idea to duplicate or automatically copy data should be anathema to anybody caring about duplicate data. Problems are bound to occur with people then changing stuff on the wrong partner. Where redundancy exists, in the long, or probably not so long, term, inconsistencies and errors are almost certain to occur.

It would be even more helpful to put the two fields approach into a mixin class, provide some standard on_change methods there and help having a consistent semantics of the different models. This mixin should be used by sale.order, account.invoice etc.

To summarize: Please use two fields pointing to res.partner, one for the legal entity, one for the physical person/location/whatever.