Comment 151 for bug 1160365

hello all,

I read carefully all comment, I test all proposed branches and here are my comments:

What I'm sure:

- We need contact and partner element (no care how) on every ERP object. When I develop a module I need to know If I am on partner object or on one of is contact / address.
- With new model un V7 we can have contact, address, partner on the same table : just create good form with only needed field and set a type pour partner (address, person/contact, department, company ..)
- Partner is the only one thing that stay between years (business definition of partner), so you can only invoice a partner, not one of his contact.

With this a give a try to odony branch, very easy:

- Create an invoice with John doo from acme corp as partner :)
- validate, pay and so.
- One day John leave from ACME, so remove john from acme

TRACEBACK

Integrity Error

The operation cannot be completed, probably due to the following:
- deletion: you may be trying to delete a record while other records still reference it
- creation/update: a mandatory field is not correctly set

[object with reference: Invoice - account.invoice]

- Ok it's normal in v6.1 it is the same ....
- So desactivate contact (uncheck active on his form view)
- Know you have on you base and invoice that pointed a partner that does'nt exist anymore. Only ACME existe and that not correct. Il you need to make a refund on this invoice, the refund is made by default to john that has leaves ACME even if he is desactivate. refund should be linked to ACME and actual invoice address should be use if exist or new ACME contact that is in charge of accounting.

So NO MORE test: partner_id should be a legal part ( a company or a person -> B2C ) and all object should be linked to it. All legal business information should stay on this entity. contact can be added for communication, email, phone, but has no legal state, just contact.

But:

- Only have one field is very convenient and simple.
- Think contact is a good granularity

so, why can you get both of two worlds ? :

- rename partner_id to contact_id in V7 modules. (contact is a good granularity, be is only a contact, not a legal entity)
- create a partner_id field that is a many2one to res.partner and default value is like you did for commercial_entity_id and make it invisible if you wish (why find a new name for a field that already exist -> partner_id) or just let people who want it to just have two fields if this is what they want.

I think the only issue is that partner_id should be link to legal entity and contact_id to contact, no more.

@fabien, @odony:

I think you where wrong when you decide to link all messaging, report on partner_id, but just replace partner_id by contact_id and do exactly the same like know, and we (partners, community members) will be able to do our job because partner stay partner and contact stay contact.

It is an extreamly important bug, lots of modules, working instances and business logics are based on this. Next time, write a road map, discuss and vote to validate choice that are so important ? We (partner, community) want to do a great job with our customers and with openERP but, for the moment we only know what you choose when a final release is published. (and I will not debate here that your final release version is no more than a first beta.)

to resume:

- I agree that we need real partner_id and contact_id (like vision of rvally and all other) It is mandatory to have both.
- I think the both approach can be reach with just an option that automaticaly calculate partner_id according to contact_id like OpenERP SA do actualy (just rename field) or let partner_id visible and contact_id visible to use it in form.

That only my point of view, reflection. I know it's a huge work, but I will be here to help to reach the right solution.
Excuse me for my poor english, and don't hesitate to comment or disagree this :)

for the moment my vote are for rvally branch because he keep partner and contact.