Comment 24 for bug 1160365

I can not understand all this big problems and issues on something that apparently is so easy to solve.
It's more... we had a solution on previous versions but this is another history and war.

I will say once and ever same thing. This is conceptual problem and if conceptually model is wrong everything will go wrong.

First issue is trying to lose normalized 1 partner several addresses model.
Addresses should be independent table always since, an address is nothing more than an address.
One address can be related to a "partner", contact, location, employee... anything that must be addressed.

So first issue will be solved. Even if you have individual partner, he could easily have 2-3 different addresses related to him. Same for an employee, same for a contact and of course for a "commercial partner" or partner as it has been known until this moment.

Second one... You want having all similar data in a single table for partners, contacts and employees... Ok, that aproach is right since it simplyfies searching, reporting and several more things... so... it's so easy as defining a type of partner directly on res.partner.
Let's say each partner_id has got a check or several that indicates what kind of information you need on it.

    is_partner: some entity that is going to invoice to you or you have got to invoice to, so it will need fiscal data, accounting data, fiscal position and so on. Partners also need several addresses, several contacts, bank accounts, basic "partner data" as dedicated salesman, etc.
    is_contact: some entity related to is_partner entities or employees entities (imagine you need registering your employees wife's data.. why not? ). This kind of entity only need contact data as email, phone, maybe several addresses but nothing more.
    is_employee: some entity related to your company needing additional data as "insurance number"or worker number not needed for "normal" contacts, so I would include a kind of inherit from is_contact.
    is_parent: only set if it's header of a group including is_partner entities. Sometimes there is groups of customers integrated in a "parent" entity that could be also an is_partner or not. On 7.0 we are loosing the possibility of registering this kind of structure.

Additionaly for reporting purposes you could set is_company or is_individual since there is some data as "company name" or "last name" on individuals that are different for both or them.

After that, only making visible or invisible some pages/fields on each kind of entity would work. This model is not impacting in any proccess since partner_id will be the correct one on each of them.

Domain is_partner should be set in every customer/supplier related documents. When needed there should be a correct address_id link correctly set (let's say invoicing, delivering address, employees home address...etc ), and when needed there should be a correct contact_id (as said for Raphaël, let's say on CRM or even sales or deliveries)

B2C and B2B will be covered on this aproach, since for B2C could exists only individual is_partner entitys not needing additional contacts or addresses, but also B2B will be covered since you could add several addresses and contacts.

But... IMHO I'm still thinking that this is a big work to do only to have advantage on searching contacts instead of really partners but if the model has to be changed/simplified I think this aproach is mantaining backward compatibility as much as posible and it's covering all possible use cases.
Please, let's doing it as easy as possible without loosing functionality and without trying to make bizarre things as copying partner fiscal data on all the related contacts / addresses.

Thank you very much:
Ana