On 03/28/2013 10:21 AM, Holger Brunn (Therp) wrote:
> 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.

Thanks for your feedback. I'm afraid there's a lot of confusion now on this 
topic because many people comment without properly understanding all the details.

For starters the system will not force you to use contacts where you don't want 
to use them. It just introduces the fact that contacts can be a valid level of 
granularity in most places in OpenERP.

The proposed solution will also take proper measures to ensure that your 
accounting and reporting is correct, while giving you the choice of the 
granularity level you want to have.


> 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.

A contact is always taken as an entity that belongs to a larger party, and it 
will delegate some of its attributes to the larger party when needed (address 
and/or accounting settings). This is transparent and means that a contact *is* 
the right reference to keep everywhere - it comes with everything you need.

The idea is that for most companies using contacts on business documents will 
be very user-friendly: not only for the B2C case, but also for B2B. And there 
is no need to duplicate the fields because a contact comes with everything that 
is needed.



> 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.

Certainly not, the whole point is that a contact *is* the right level of 
granularity in most documents. And since it will come with correct data (incl. 
accounting/invoicing), there should be no need to modify any module.

If you don't agree with this, then you don't agree with the fact that contacts 
are a valid level of granularity.


In fact the "two-field approach" will need to patch a lot of modules, otherwise 
the "contact" will simply be ignored. If users create documents for a contact, 
they will expect to be able to find it everywhere under that reference. It 
won't be the case unless all search views/list views/reports are modified to 
also include the "contact" info. If this is not done the contact field will be 
a mere useless decoration - and will actually create the opposite confusion. If 
it is done you have a lot of code and duplication of information. And it would 
not prevent users from entering payment terms on contacts, etc.


> 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.

That's why part B of the solution says:
   "when a partner is not an commercial party, the form view will be modified: 
the Accounting tab and the Invoicing section of the Sales&Purchases tab will be 
replaced by a note that says something like "Invoicing settings are controlled 
on <link to commercial party>"

So it will be very clear for the users.

In fact, please see the "data copy" as a technical implementation detail on how 
contacts delegate some of their attributes to their parent, nothing more.


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

I think this issue is very hard to discuss on theoretical terms. I suggest the 
following: I'll finish the merge proposals, and instead of talking 
theoretically, everyone will be able to test the solution and see if and where 
*real problems* arise. And by *real problem* I don't mean "different behavior 
than in 6.1", but "real business issue that produces undesirable/unexpected 
behavior".

Thanks a lot for your patience and your careful analysis.