On Wed, Mar 27, 2013 at 6:18 AM, Olivier Dony (OpenERP) <
<email address hidden>> wrote:

> [...]
> accounts, payment terms, etc.). The list of fields to copy will be
> returned by
> a method on res.partner that can be overridden in other modules."
>
> Or did you mean something else?
>

Sorry this is answers to my question indeed. Now I'm still far from
convinced as for the general idea and give a few more clues in the
following.


> > And again, what is the advantage over adding a contact_id field?
>
> It's simply in line with the concept of the 7.0 model. Adding a contact_id
> field would defeat the purpose of the new model:
> - it would cause useless duplication of fields: in the 7.0 model a contact
> is
> really meant to be a first-class partner, and it is responsible for
> delegating
> its properties when needed to a parent company.


Wait a minute, do you never duplicate fields for reporting purpose? Why for
instance sale.order.line do have a order_partner_id field while you could
infer it from the related order already for instance?
So SQL matters and reporting matters. I come back on this.



> So any partner
> (contact/address/company) must encompass the full range of attributes
> without
> requiring any direct pointer to its parent. A direct link to second partner
> should only be required when there is a user choice involved (such as when
> an
> different Invoice Partner or Delivery Partner can be chosen on a SO). In
> all
> other cases a single partner reference must be enough, that's the whole
> point.
> - it validates the fact that a contact is the right level of granularity in
> most cases. Adding a second "parent" field in all cases would mix
> granularity
> levels.
>

No!
By using the same partner_id field who is mixing granularity levels is you
instead!
Now every OpenERP report grouping by partner_id will randomly group by
company or by company contact, depending on what user will have selected.

If you have two fields: contact_id AND partner_id, then
if you want to do an analysis by company you can
if you want to do an analysis by contact you can also
but at least you have the choice!


>
> Basically if we introduce the 7.0 model *and* start adding extra partner
> fields
> on all business documents, we're adding confusion/overhead rather than
> simplifying.
>

I strongly disagree with this view.
"we're adding confusion/overhead rather than simplifying" who for Olivier?

more confusion for the user?
if you add that contact_id field, you can then hide the partner_id field
(and set it properly via an on_change), that is the USER WILL STILL SEE
ONLY ONE FIELD in business document and he will still be able to mix
companies, physical persons and contacts in that contact_id field.
So sorry, functionally speaking I see no difference at all with what you
try to achieve while taking many risk with changing the partner_id semantic
in the middle of a release without any preparation as this bug just proves.

more confusion for the developer then?
Come on, how adding just that little contact_id field in purchase orders,
sale orders and invoices will loose developers?
At the object level that contact_id field will be optional and you can fill
it with the partner_id by default when partner_id is present if you like.

So what is more confusing for the developer please:
1) having 3 additional contact_id fields in OpenERP ?
or
2) or having to deal with all foreign keys comparisons against partner_id
in all the core and community codebase because now partner_id can randomly
be the company or any of its contacts and you are trying to make us believe
that the code will work exactly the same with no need for any special care?
(the problem exists right now, we aren't planing for next release so saying
you will investigate deeply for possible issues isn't exactly an option
because this is already an afterthought on a mission critical system).
AND having to work on all your report to find a way to relate properly
business documents that relate to the same company but that don't have any
foreign key in common any more? (as partner_id can now be the company or
any contacts depending on what user types)


I claim that the day you will look at reporting by company seriously (at
least), you will be forced to add that "commercial_entity_id" stored field
on business documents (in 7.1 in 8 as you said not now in 7.0?).

AND I CLAIM that when you will add that commercial_entity_id field, then
the whole stupidity of the solution planned now by OpenERP SA will be
totally obvious:

   - that new commercial_entity_id store field will be exactly what
   partner_id has been all these years.
   - you will still have added a field in business documents, but not the
   right one!
   - you will have faced dozens or hundreds of regressions because you
   changed the partner_id semantic in the codebase with no anticipation and
   you will possibly have made the OpenERP codebase slower and more complex
   when trying to fix these issues one by one (for instance methods having
   just a partner_id input may need to hit the database to find all the
   company contacts before creating some domain/select)


Are you still so sure it's the right solution? Thanks.