Comment 115 for bug 1160365

On 04/11/2013 10:09 PM, Ana Juaristi Olalde wrote:
> Problem is that you still think that correct
> granularity level is contact, since people all over the world think that
> correct level is partner.

Yes we do, and it looks like several people agree that contact is a correct
level of granularity in many cases. To me the voiced concerns here are more
about the way this change was conducted, its timing, the known consequences to
existing SQL reports and "group by", and worries about unknown consequences to
modules that would rely on the "company" level of granularity.
We can certainly understand those reactions, and we're really trying to address
them.

I think very important progress was already done and key issues spotted thanks
to everyone's contributions on this bug report!

> IMHO i still think it is a big mistake changing level of granularity,
> giving priority to a secondary entity as it is contact instead of first
> level granularity entity as it is company.

A contact *does* always carry the company information, so it is a correct
primary entity because it contains everything. It is not "contact Y" but always
"contact Y in company X". If we treated it as a secondary entity that can be
lost across transitions between business documents, we *would* lose very
important information.

So yes, community modules will need to be adapted to v7, but the task should
not be that big. OpenERP 7.0 removes the res.partner.address model and this
requires a proper migration of all modules that deal with partners/contacts
anyway. So you can think of this as sanity checks to perform when migrating any
6.1 module:
  1. Can the m2o fields to res.partner.address be dropped now that partner_id
is directly a contact, or do they need to be replaced with extra m2o to
res.partner? (+ think of the proper migration of existing data for this case)
  2. When 'partner_id' is used in the module, do we need to be careful that it
could be a company contact rather than a "commercial entity"? (As all
commercial fields are correctly delegated to the company, this should mostly
matter for low-level accounting modules and accounting SQL reports)
  3. Given that partner_id could be a contact, should I change my search views
to make it easier for users to locate documents of contacts when they search on
the name of the company? (i.e. use child_of)

Your core accounting will be safe and invoices will carry both fields and the
partner balance will be right, so there won't be any bad surprises there.

For the rest, please try OpenERP 7.0 (the branches linked to this bug) with
your real customer use cases and see if/where you can spot blocking points.

Thanks again!