Comment 178 for bug 1160365

Daniel,

Here is a presentation about the "Why" we did that change:
  http://bit.ly/17eMp8F

If not about social aspects.
It's because it better reflects the real life.

On 04/15/2013 03:54 PM, Daniel Reis (SECURITAS SA) wrote:
> It seems to me that the central issue is the "change in granularity level".
> There are a lot of qualified people discussing the what, where & how, but it seems that the WHY is yet to be explained.
>
> Why "contact" is to be "the right level of granularity"?
> ========================================================
>
> WHY the change?
> What's OpenERP's reasoning behind this?
>
> I've been trying to read their mind, and I decided to contribute to the discussion because I think I've figured it out.
> For me the key was in Fabien's comment #120 (https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/120).
>
> V7 is about Social:
>>From a legal POV, your company interacts with other Companies.
>>From a social POV, your users interact with other Company's people.
>
> For OpenERP to be social, it needs to interact with a Contact@Partner instead of a "pure" Partner.
> This way it can send emails to Contact@Partner, instead of Partner's generic e-mail,
> or let Contact@Partner interact using a personal Portal user account, instead of a Partner generic one.
>
> Thus the need for the "change in granularity".
>
> Everyone is assuming that a Contact it's a Person working for a Company
> But it's not - it's more like a Job/Position at a Company.
> It's a "Contact@Partner": a Contact *at a* Partner; a Partner plus a point of contact info.
> It's actually just a face, an alias, for the Partner.
>
> But it breaks the commercial entity reference on documents?
> Not in the simple, flat, partner structure you get out-of-the box on v7:
> On the flat structure Partner 1->N Contacts, you just need to use `partner_id.parent_id`
> where you used `partner_id` and there you are: you get exactly the same info as before.
> This can also be easily achieved in SQL with just as additional join.
>
> Explained like this, it looks like, despite being a big change, there seems to be no big deal,
> and that you can do everything you could do before with pretty much the same effort.
>
> And if the your ContactX@Customer1 person goes to work at Customer2, you don't edit Contact1:
> You inactivate ContactX@Customer1 and create ContactX@Customer2!
> Because "ContactX" does not make sense on itself on the new model.
> It only makes sense to have "ContactX@Customer1" and "ContactX@Customer2".
> And if the ContactX personally is also your Customer, then you need to also create "HomeAddress@PersonX".
>
> Do I sound like Fabien and Olivier right now? I hope I do.
>
> Problems came when you were able to mix "Contacts at Partners" and "Pure Partners"
> on the same field, and that a lot of v7 localization ports to v7 was done assuming that
> partner_id is still a company ... and when you need to add a hierarchy to the Partner table ...
> But that's the already discussion going on .
>
> I hope I contributed to a better discussion.
> I'm not swimming in VC funding over here to offer a case, but I promise to bring a couple of Port wine bottles
> to the OpenERP days if a solution good enough for everyone is achieved.
>
>
> PS: Raphael's code was just a proof of concept for a solution.
> Everyone, including Raphael, prefers a solution from OpenERP SA implemented directly in the core.
> OpenERP SA should be thankful to have such an involved community, with people as skilled as Raphael.
> Having said that, Raphael - I want a bottle from that case.
>

--
Fabien Pinckaers
CEO OpenERP
Chaussée de Namur 40
B-1367 Grand-Rosière
Belgium
Phone: +32.81.81.37.00
Fax: +32.81.73.35.01
Web: http://openerp.com