On 14/04/13 20:20, Michael Telahun Makonnen wrote:
> +1 for partner_id + contact_id

Why not partner_id + commercial_id ? This would be the solution to 
satisfy everyone's need.

> @ fabien said in reply #146:
> " As you may know; users should never change the company of a contact
> because the contact started to work for another company. The only valid
> reason [1] to change the company of a contact is because you fix a
> wrongly created record. And, for those that want to handle contacts that
> change of companies, we have the base_contact module for this.
>
> Your problem is not related at all with the current discussion. It just
> points out a usability issue which is that a user may change the company
> of a contact for an invalid reason. "
>
> You can't have it both ways. Either the contact is a "first-class"
> object or it isn't.

"John Doe, Acme" is a first-class object, not "John Doe". If you want to 
manage "John Doe" as a person, you need base_contact module (it's not 
related to our solution, it's the same in v6.1 and in raphael's 
proposition too).

> If it is a first-class object then it should
> represent a real world person. When a company changes address you change
> the company's address. You don't create a second company with a
> different address.  If John Doe changes company you should change John
> Doe's address to the new company and OpenERP should still behave
> correctly.  It's disingenuous of you to blame the inconsistencies in
> your data model on the user.

As I said, it's not related to our solution, it's the same in v6.1 and 
raphael's proposition too.

> No one disagrees that a contact should be a first-class object in the
> database model.  I like it and pretty much everybody else also seems to
> like it.  The problem we have with that is when you take that and apply
> it to the business model (I am making a distinction between the data
> model and the business model).  In the business model a contact is not a
> first-class object. The first-class object is always the entity you have
> a business relationship with (ie. the company). The contacts are
> incidental to this relationship and they can change, disappear, whatever
> without affecting the relationship whatsoever.

The person "John Doe" can die. But, in the database, the entity "John 
Doe, Acme" can not disappear. Because, in the real life, this 
information does not disappear: your contracts are signed "John Doe, for 
ACME", you can not remove the signature "John Doe" and keep only "for 
ACME" on all contracts. That's why contacts can not be deleted but they 
can be set as not active anymore.

> So when you send an
> invoice you can send it to the contact, but the recipient should be  the
> company, not the contact. Notice, I didn't say it should be addressed to
> the company. It's a subtle, but very important distinction.

Yes, we do agree with that.

That's what we do in our implementation:
   - address: partner_id.street (the contact)
   - receivable: partner_id.commercial_id.account_receivable.id (the 
company)

With partner_id.account_receivable.id == 
partner_id.commercial_id.account_receivable.id.
Because partner_id is "John Doe, Acme", not "John Doe".

> > From your addition of a 'commercial_id' field to res.partner it seems
> like you also acknowledge that there is at least *a* distinction...
>
> ... Which leads to the next problem we have: So, if you acknowledge the
> need for a 'commercial_id' why do you have to "silently" change the
> semantics of a very important field implicitly acknowledged by your
> pre-7.0 data *and* business model as the "commercial_id" but misspelled
> as partner_id?

As we defined that "John Doe, Acme" is a first-class object, it's normal 
to use it for partner_id.
Most documents need only one field "John Doe, Acme" as this record 
includes both information (the contact and the company).

Sometimes, it's convenient to add commercial_id on documents to ease 
reporting (group_by) but usually we do not need it
because commercial_id is given by partner_id.commercial_id. If we need 
it on the document, we just add a related field.

> Keep the misspelling and put the contact in its own field
> called contact_id. By your own acknowledgement the contact was a rarely
> used feature in previous versions. So I have to believe that from the
> point of view of creating the least disruption this is the simplest
> solution that is the closest to the business model.

It's still a matter of point of view.

> Lastly, you've stated that one of the reasons for not going the
> partner_id + contact_id route is that it would change the 7.0 database
> schema.  This is a moot point.

We don't want to change the semantic of the existing schema, but we 
agree to add fields because we can do that through new modules.

> There would have been no need to change
> the schema had all this been discussed with your community before hand.
> The fact that we are contemplating changing the schema now, after 7.0,
> is as a result of OpenERP SA not having thought out the implications of
> its changes completely before releasing 7.0 to the world and should not
> be held against the community.

We showed this schema during the community days 2012, one year ago. It's 
in trunk since 9 months.
But I agree that we are not good in communication. We should have better 
explained all the changes
of v7.

Fabien