Comment 135 for bug 1160365

> I do not feel that you are addressing my issues.

No, I just said we are turning around with the same discussion again and again. And I said we already answed with our point of view in previous comments.

But I can do it one more time, if you want.

> It is not about whether
> Olivier's code implements the principles that you set out correctly, it
> is the principles themselves. I am sure that Olivier is capable enough
> of copying data around in a relational database, but it is simply bad
> practice to do so.

Our point of view is "the contact can represent the company". Your point of view is "the contact is just a contact".

According to our point of view, it's completly normal to have the right data on the contact record (pricelist, company address, fiscal position, ...) So, it's not a bad practice, it's logic according to the definition we gave to a contact. (It's also very usefull: data are always correct on every record of the DB, modules do not have to compute which is the right record handling data according to the transaction)

Suppose we have this structure:
   OpenERP SA [is company: true]
       OpenERP GR
           Accounting Dept
       OpenERP Bruxelles
           Sandro Botta

Why do we think that a contact is the right level of granularity for all data when dealing with a company?
  - the address to send the quote to must be the one of the contact, not the company
  - the delivery address to use depends on the contact, not on the company (If Sandro buys sth, we have to deliver in Bruxelles, not in Grand-Rosiere, even if both GR and Bruxelles are defined as valid delivery address, and sandro is just a contact)
  - the pricelist depends on the contact, not the company
  - even the fiscal position may depend on the contact, not on the company

In a lot of companies these data (address, pricelist, fiscal position) are the same for all contacts of the company. So, for useability reasons, we did a system to allow sharing easily the address amongst all contacts (use company address).

The other data (pricelist, fiscal positions) are common amongst all contacts of the company in 99% of the businesses. So, for useability reasons, we inherit these information from the company for every contacts to simplify recording of data. (same than in v6.1: same pricelist/fiscal position/... for all localisation of the company)

But in real life, you could imagine having different pricelists negociated with different departments of the sale customer (or even fiscal positions, depending on the country of the department). That's why our data model better reflects the real life. (you can easily do a module if you are in the 1% of businesses dealing with several pricelists depending on the department of the customer)

> I can see that it is possible to retrieve the company
> partner for any business document using some Python code, but not having
> them linked directly is pretty odd for an ERP. I can see that having a
> partner_id and a commercial_entity_id, provided by a separate module
> gives a complete set of information, but it changes the meaning of
> partner_id around which causes inconsistent naming in the core (compare
> the use of 'partner_id' on the accounting models) and incompatibility
> with legacy code. It also creates the need for an uncertain amount of
> such modules to complement other models.

Yes, community modules will need to be adapted to v7. But community modules need to be adapted anyway, for lots of other reasons: res.partner.address removed, new view format, ... And the adaptation due to partner_id is short and trivial.

We usually try to minimize breaking compatibilities between versions. But, sometimes, the improvement is worth the change. I think the res.partner change is a huge improvement.

Why is it worth the change?
Because it handles lots of usecases not efficiently handled by the v6.1 model.

  - Clean separation on concepts, that better reflects the law: "companies & persons" rather than "partners & addresses"
  - Clean address book: In v6.1, "partners" was used to store a mix of companies and contacts, whereas "contacts" was used to store company contacts and persons's addresses.
  - B2C: just imagine than, in v6.1, B2C companies had to record two times the same data on every form. As an example for a sale order; partner: john doe, address: john doe. More over, if they clicked on the "contacts" menu, they did not get their contacts, but just their addresses.
  - Useability / productivity of users: the v7 model allowed to remove one field on every screen, without loss of information (unnecessary redundancy)
  - V7 handles cleanly hierarchies inside companies whereas it was not possible in v6.1 (this can be mandatory to handle some use cases)
  - No redundancy, or inconsistency possible in v7, as an opposite to v6.1 where it was possible to sell to "john Doe, Acme" but with partner "Emca". V5.1 required two fields to represent one single concept "who purchased".

> In my post I argued that the changes in the 7.0 datamodel is
> unnecessarily disruptive. Its consequences cannot be tested by a small
> team of community members. Instead, our customers will be the guinea
> pigs testing the changes and we have been told by them in the past that
> they do not appreciate it. We will also encounter the real problems when
> discussing with them the management reporting that they need, or when
> they want to talk about customizing the semantics of partners and
> contacts for their own needs. We cannot anticipate and test every
> scenario at this point. The principles underlying the 7.0 datamodel and
> the proposed solution undermines the stability of OpenERP and to be
> honest, we have problems enough with it already in terms of number of
> bugs that exist.

This is why we say: "please test by yourself instead of claiming this". We think this fear is not justified. We implemented this model in trunk nearly one year ago. We use it for our own company since 4 months.

Olivier's change has strictly no impact on business documents (he just changed the partner object), as an opposite to raphael's proposition that create side effects on every business documents.

More over, it does not break compatibilities that much.

> Keeping the partner_id semantics the same as in earlier versions means
> less code changes means less bugs. That is currently a high priority.
> Our customers expect a product to mature in that sense. We cannot
> suggest our customers to migrate to 7.0 if it means more instability or
> paying to create customizations to implement core functionality that
> existed in an uncustomized older version.
>
> In terms of functionality, we surely agree. Having the contact as the
> starting point of every business document is a good thing to have. So
> please consider the approach that we favour. Raphaël's idea to keep
> partner_id semantics in tact and add the contact_id for the user to work
> with is very transparent, suits your purposes fine, can be implemented
> elegantly and brings less instability. So please confirm if you can be
> pragmatic about a minor set of database changes in 7.0 and we will give
> you something to test.

As Olivier said, the problem of raphael's branch is not that he tried to limit changes. The problem is that he tries to simulate the v6.1 logic on top of the v7 data model/semantic which as no sense.

This leads to:
  - a lot of side effects as he impacts all business documents
  - a wrong usage of objects according to how they have been developed

But the main reason is that we disagree on the principle: raphael wants to revert the logic to simulate v6.1, we think the logic of v7 is a strong improvement.

We did not see any valid argument against this in this discussion. So, there are no reason to try to revert everything. It's better to move forward to the right direction.

Thanks,

Fabien