[7.0] incorrect handling of contact/companies for invoicing and related purposes

I'll be working on merge proposals to address the different parts of the solution described above, they should be available for review by the community soon.

@Olivier

thanks for the good summary of the issue and the way you see a solution today.
Now sorry this is still unclear to me, and I'm still worried you try to fix it the wrong way.

So are you YES or NO actually going to add new contact_id fields on business documents? (like we were referring as the B) solution in the original bug) ?

You says "A) Let the "commercial party" for a partner be the person or company that is used as reference for all invoicing/accounting matters"
Is that supposed to be the existing partner_id field or a new field (stored or not) ?

Because if that "commercial party" is the regular existing partner_id then we agree on the solution. Else I claim you are still getting it wrong...

Again not clear for me when you say:
"C) When a contact/address is selected as the reference for a business document (SO/PO),"
So do have that additional contact_id field (as we are advocating since the beginning) setting that proper "commercial entity" with the logic you described on the existing partner_id field or is that some kind of blind faith you would solve it differently?

Now, may be you still plan to allow selecting the contact in partner_id and may be we still not agree.
I'm specially worried when you write:
"2) Any code in business modules that deals with invoicing/accounting related data should automatically use the data of the "commercial party", thanks to B, because the data should always be in sync."

How that Olivier?
Look at the following piece of code in the account/account_invoice.py file (there are dozens of such cases if not hundreds considering also the sale, purchase, stock and main community modules):

pay_pro_id = property_obj.search(cr,uid,[('name','=','property_account_payable'),('res_id','=','res.partner,'+str(partner_id)+''),('company_id','=',company_id)])

You can make a contact inherit whatever you want form its parent company: if partner_id is suddenly allowed to be just the id of the contact record, that property search will fail to find the property attached to the company record one.
But this is just a quick example: any search/domain involving partner_id will not work out of the box at all and lead to regressions very hard to spot.

Also, I strongly advocate for keeping partner_id the same id between business documents such as invoices, sale and purchase orders. Because else you would really make analysis over complicated for no benefit at all. Imagine also all the action_window showing related invoices, orders, payments all based on partner_id. All this has to keep working with no regression!

So when I read "We think the solution should be mostly handled by the res.partner model itself". Well if you don't add these contact_id fields on business documents (as it was your plan until now apparently) I fear you are lying to yourself or to your community.

So sorry, this is not clear to me yet. You say "contact/address" is the right level of modularity. Well, I agree and if you add that contact_id field on business documents, you will still be able to perform any analysis at the contact level if you want to. So no detail would be lost.

Also, I would like to insist that reading accounting/financial/fi...

On 03/26/2013 04:03 PM, Raphaël Valyi - http://www.akretion.com wrote:
> So are you YES or NO actually going to add new contact_id fields on
> business documents? (like we were referring as the B) solution in the
> original bug) ?

No, the proposed solution doesn't include that. The idea of unifying the
partner structure in 7.0 is that a contact is a first-class partner. It can
sometimes delegate some of its properties to a parent entity (or copy them),
but for most purposes it can be used directly.

> You says "A) Let the "commercial party" for a partner be the person or
> company that is used as reference for all invoicing/accounting matters" Is
> that supposed to be the existing partner_id field or a new field (stored or
> not) ?

It's not a stored field, it's a definition. It could be a new stored field in
the future, as I mentioned in the "Further refinements" section, but that's not
planned for 7.0.

> How that Olivier?
> Look at the following piece of code in the account/account_invoice.py file
> (there are dozens of such cases if not hundreds considering also the sale,
> purchase, stock and main community modules):
>
> pay_pro_id =
> property_obj.search(cr,uid,[('name','=','property_account_payable'),('res_id','=','res.partner,'
> +str(partner_id)+''),('company_id','=',company_id)])

This (rather ugly) code will work just fine with the proposed solution AFAICS.
If the account_payable property was explicitly set on the parent company, it
will be copied to its contacts (that's part B), so this code will find it. If
not, it will fall back to the default for the property in both cases.

> You can make a contact inherit whatever you want form its parent company: if
> partner_id is suddenly allowed to be just the id of the contact record, that
> property search will fail to find the property attached to the company
> record one. But this is just a quick example: any search/domain involving
> partner_id will not work out of the box at all and lead to regressions very
> hard to spot.

We think it will work in most cases, and we will be searching for possible
issues before finalizing the solution. If some can be identified we'll have to
examine the options.

> Also, I would like to insist that reading accounting/financial/fiscal data
> isn't limited to the account module. For instance, in many situations
> (specially sales bewteen sovereign states such as international commerce or
> inside federal countries), you may need to read fiscal data right from the
> sale order to find out the right taxes to display. So for instance if
> partner_id can be a contact in a sale order or a purchase order, well all
> the fiscal-rule framework (a pillar for our localization but also used in
> international e-commerce) is broken
> https://launchpad.net/openerp-fiscal-rules

By default all invoicing/accounting-related data will be copied/synced by the
res.partner model itself; the account module will simply extend the list of
fields to sync. If extra partner fields are added by other modules they can
presumably extend the list of fields to sync, just like account would do it.

Could you explain with a specific example what would not work based...

On Tue, Mar 26, 2013 at 12:50 PM, Olivier Dony (OpenERP) <
<email address hidden>> wrote:

> On 03/26/2013 04:03 PM, Raphaël Valyi - http://www.akretion.com wrote:
> > So are you YES or NO actually going to add new contact_id fields on
> > business documents? (like we were referring as the B) solution in the
> > original bug) ?
>
> No, the proposed solution doesn't include that. The idea of unifying the
> partner structure in 7.0 is that a contact is a first-class partner. It can
> sometimes delegate some of its properties to a parent entity (or copy
> them),
> but for most purposes it can be used directly.
>

The refactor of v7 is nearly good. Indeed it's interesting to have a
"Party" super type now.
But because you now have contacts and companies being both sub-types of the
res.partner or "Party" super type, it doesn't mean you
can exchange them anywhere as if they were the same things.
As I said, I think it's like some python functions can work with numbers,
that is both integer or floats. But some functions require an integer and
not a float.
I claim today OpenERP business document codebase only work if partner_id is
a company or a physical person, but not if it's just a contact. I think
this is an abuse to try to quickly opt for having to change an undefined
amount of code to try to adapt the code to make it work with that new
contact semantic in the middle of what was announced as a stable release
while nothing has been anticipated here.

Now, yes, some non business documents can now transparently use a contact
or a company. For instance it's cool you can send a message to a company or
to a contact in a transparent way. Some views are simpler too. All this is
positive.
But IMHO without anticipation and absolute care, type generalization should
be the exception rather than the rule! But here it rather seems that
debugging these regressions is rather an afterthought after by luck the
community spotted them in your LTS 3 months after official release.

> > You says "A) Let the "commercial party" for a partner be the person or
> > company that is used as reference for all invoicing/accounting matters"
> Is
> > that supposed to be the existing partner_id field or a new field (stored
> or
> > not) ?
>
> It's not a stored field, it's a definition. It could be a new stored field
> in
> the future, as I mentioned in the "Further refinements" section, but
> that's not
> planned for 7.0.
>

That would be interesting to have it stored, wouldn't it?
For reporting, for making SQL base reports by company work again...

But wait a minute: wouldn't that be stupid to add it as a NEW stored field
instead of using that partner_id with the same semantic it always had and
the low level of bugs it took nearly a decade of tireless community
debugging to achieve?
If it's for getting reporting right, isn't it smarter then to add new
contact_id field instead to store the contact and keep partner_id untouched
with no risk taken?

>
>
> > How that Olivier?
> > Look at the following piece of code in the account/account_invoice.py
> file
> > (there are dozens of such cases if not hundreds considering also the
> sale,
> > purchase, stock and main community module...

Note: copying invoicing/accounting data from parent "commercial party" to descendants cannot be done for one2many relationships. Currently the only case we identified is the list of bank accounts. Those will not be duplicated and should only ever be used in the context of the parent - similarly to the way payable/receivable entries are all linked to the parent directly. We'll double-check that it is the case everywhere. We should probably raise an exception if a module tries to add a one2many field to the list of accounting-related fields to sync between parent and contacts.

And as for the benefit of trying to fix this way instead of simply adding contact_id fields? Could you elaborate please?

Hi Olivier

Can you check my comment here https://bugs.launchpad.net/openobject-addons/+bug/1155679/comments/26 ?
How do you solve this problem if we have only on field contact on invoice? Did I miss something in the solution proposed?

Hope this can help you. Thanks for your time

@Sebastien
If Mr. Dupont starts working for company B, you have to create a Mr. Dupont for Company B (instead of moving mr. dupont from company a to company b) like you would do for any subsidiary. So, you have Mr. Dupont working for company A (<email address hidden>, phone: companya+dupontsuffix, ...) that you can desactivate if you want and mr. dupont working for company B who are two different persons.

But, if you want to manage one persone working for several companies, you can install base_contact. It allows to manage data related to persons (Mr. Dupont) and not only to their role within their company. With the new base_contact module (7.0-base-contact-xal on runbot) you can handle it without problems. It will work perfectly: 1 person Mr. Dupont, 2 contacts (Mr. Dupont Company A & Mr. Dupont Company B)

@raphael
> Wouldn't that be by kind of "overriding the read of res.partner" to read the value from
> the parent_id in case of a company contact as I described in A) ?

No, overwriting the create and write, so that all contacts have the right data in the DB.

When you write on the main company, it will write the same to data to all children contacts. That's what we already do for contacts that share the address with the company and it works fine in v7.

> @raphael
> > Wouldn't that be by kind of "overriding the read of res.partner" to read
> the value from
> > the parent_id in case of a company contact as I described in A) ?
>
> No, overwriting the create and write, so that all contacts have the
> right data in the DB.
>
> When you write on the main company, it will write the same to data to
> all children contacts. That's what we already do for contacts that share
> the address with the company and it works fine in v7.
>

@Fabien, this enable reading the proper data inside the contact record.

But
1) how will you decide which fields exactly are copied or not?
2) how does it scales across modules adding fields in res.partner, which
fields will be copied or not?

And mostly
3) what about all the existing business logic that makes a decision by
taking some arbitrary foreign key pointing to the res.partner table and
comparing it with partner_id. What leads you to warranty us with so much
assurance that the code will always be consistent with the expected
behavior if partner_id can now randomly be the parent company or any of its
contacts?
So for me, out of the box, sometimes there will be a match and sometimes
not. While until v6.1 the code always assumed it should match if that's the
same partner_id company, no matter what user selected as the contact.
I gave several examples of them in a previous comment without having to
search a lot.

IMHO you are not considering this pitfall enough.

And again, what is the advantage over adding a contact_id field?
You want to be able to use contact_id anywhere because you believe this is
better (I don't, I think this predates the reporting and business data
integrity). But is there any urgency to try to make this new feature work?
Having so many strong indicators regressions will not be detected nor fixed
easily, shouldn't we better adopt a conservative stance that is FIRST do a
solution that protect us against regressions AND THEN eventually implement
the new feature in a next release, while taking all the care to guarantee
there is not a bunch of hidden regressions BEFORE releasing?

My 2 cents.

2013/3/26 Fabien (Open ERP) <email address hidden>

> @Sebastien
> If Mr. Dupont starts working for company B, you have to create a Mr.
> Dupont for Company B (instead of moving mr. dupont from company a to
> company b) like you would do for any subsidiary. So, you have Mr. Dupont
> working for company A (<email address hidden>, phone: companya+dupontsuffix,
> ...) that you can desactivate if you want and mr. dupont working for
> company B who are two different persons.
>
> But, if you want to manage one persone working for several companies,
> you can install base_contact. It allows to manage data related to
> persons (Mr. Dupont) and not only to their role within their company.
> With the new base_contact module (7.0-base-contact-xal on runbot) you
> can handle it without problems. It will work perfectly: 1 person Mr.
> Dupont, 2 contacts (Mr. Dupont Company A & Mr. Dupont Company B)
>
> @raphael
> > Wouldn't that be by kind of "overriding the read of res.partner" to read
> the value from
> > the parent_id in case of a company contact as I described in A) ?
>
> No, overwriting the create and write, so that all contacts have the
> right data in the DB.
>
>
Regarding this point....

> When you write on the main company, it will write the same to data to
> all children contacts. That's what we already do for contacts that share
> the address with the company and it works fine in v7.
>
>

In my opinion, this is worng implemented, so easy to make big mistakes,
and left db broken (from a functional PoV)

I think the idea is cool, but this is ona of things i change in our
localization.

FISCAL INFORMATION is composed by:

Address, VAT Number,
(Internal Country Number if you need more than once),
NAME,
(last name if it is necesary for Natural people),
Fiscal Position >> With human process to change it.
Accounting important ones:
=====================
Payment terms
PriceList
Accounts payable and receivable
Banks.

IMHo these are minimal ones.... and as i said before, it not a technical
deal that can be solved just in write or create.

It must be developed with intention of avoid human hidden mistakes, until
now i think the idea is good as it is in V7.0 but it has A LOT of
functional probelms, because it so easy make human mistakes.

IMHO the main issue here is that we solved this already in V7.0 and nobody
take in to account our needs with the change in V7.0 we redeveop again, no
problem, but by default we have a lot of probelms here.

I think.

Manage carefully create and write (better than what is done now, more
messages, more mittake - control, better process management in terms of
documentation)
Take ALL fiscal information from parent if it is a company :

Techinically it should be a method called

def _get_fiscal_data(self, .....):
    return {fiscal dict}

And the core overwrite the read method.

def read(....):
    return self._get_fiscal_data(....)

If it is not done in this way, we will handle A LOT of thinks in ,maturity
time

What do you think guys?

> --
> You received this bug notification because you are subscribed to OpenERP
> Project Group.
> https://bugs.launchpad.net/bugs/1160365
>
> Title:
> [7.0] incorrect handling of contact/companie...

2013/3/26 Raphaël Valyi - http://www.akretion.com <
<email address hidden>>

> > @raphael
> > > Wouldn't that be by kind of "overriding the read of res.partner" to
> read
> > the value from
> > > the parent_id in case of a company contact as I described in A) ?
> >
> > No, overwriting the create and write, so that all contacts have the
> > right data in the DB.
> >
> > When you write on the main company, it will write the same to data to
> > all children contacts. That's what we already do for contacts that share
> > the address with the company and it works fine in v7.
> >
>
> @Fabien, this enable reading the proper data inside the contact record.
>
> But
> 1) how will you decide which fields exactly are copied or not?
> 2) how does it scales across modules adding fields in res.partner, which
> fields will be copied or not?
>
> And mostly
> 3) what about all the existing business logic that makes a decision by
> taking some arbitrary foreign key pointing to the res.partner table and
> comparing it with partner_id. What leads you to warranty us with so much
> assurance that the code will always be consistent with the expected
> behavior if partner_id can now randomly be the parent company or any of its
> contacts?
> So for me, out of the box, sometimes there will be a match and sometimes
> not. While until v6.1 the code always assumed it should match if that's the
> same partner_id company, no matter what user selected as the contact.
> I gave several examples of them in a previous comment without having to
> search a lot.
>
>

Ouch, you are right Raph.... I forgot this...

One time this wrapp method i mentioned before is done....

We(Openerp Sa) must to make a find (*.patner_id) in all addons, and read
manually when it is taking fiscal or accounting information and change by
the correct "read" method.

Probably the browse too? i dont know.

Regards.

> IMHO you are not considering this pitfall enough.
>
> And again, what is the advantage over adding a contact_id field?
> You want to be able to use contact_id anywhere because you believe this is
> better (I don't, I think this predates the reporting and business data
> integrity). But is there any urgency to try to make this new feature work?
> Having so many strong indicators regressions will not be detected nor fixed
> easily, shouldn't we better adopt a conservative stance that is FIRST do a
> solution that protect us against regressions AND THEN eventually implement
> the new feature in a next release, while taking all the care to guarantee
> there is not a bunch of hidden regressions BEFORE releasing?
>
> My 2 cents.
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Project Group.
> https://bugs.launchpad.net/bugs/1160365
>
> Title:
> [7.0] incorrect handling of contact/companies for invoicing and
> related purposes
>
> Status in OpenERP Addons (modules):
> In Progress
> Status in OpenERP Server:
> In Progress
>
> Bug description:
> == Problem Description ==
>
> This issue is an attempt to formalize the various problems detected
> with the res.partner refactoring that took place in OpenERP 7.0. Some
> of the issues have already been d...

One more thing....

@Fabien,

As always, you should design a generic method in accounting for example to
wrapp always your logic, IMHO if you do that at least in terms of partners
and products (to main object in fiscal recording data) AND rebuild
everything in terms of this accounting API you will avoid A LOT of
regressions.....

Because solve problems in this method will help us (Localization makers and
mantainers) give quick and fast solutions for our laws.

What do you think?

Regards.

2013/3/26 Nhomar Hernández <email address hidden>

>
>
> 2013/3/26 Raphaël Valyi - http://www.akretion.com <
> <email address hidden>>
>
> > @raphael
>> > > Wouldn't that be by kind of "overriding the read of res.partner" to
>> read
>> > the value from
>> > > the parent_id in case of a company contact as I described in A) ?
>> >
>> > No, overwriting the create and write, so that all contacts have the
>> > right data in the DB.
>> >
>> > When you write on the main company, it will write the same to data to
>> > all children contacts. That's what we already do for contacts that share
>> > the address with the company and it works fine in v7.
>> >
>>
>> @Fabien, this enable reading the proper data inside the contact record.
>>
>> But
>> 1) how will you decide which fields exactly are copied or not?
>> 2) how does it scales across modules adding fields in res.partner, which
>> fields will be copied or not?
>>
>> And mostly
>> 3) what about all the existing business logic that makes a decision by
>> taking some arbitrary foreign key pointing to the res.partner table and
>> comparing it with partner_id. What leads you to warranty us with so much
>> assurance that the code will always be consistent with the expected
>> behavior if partner_id can now randomly be the parent company or any of
>> its
>> contacts?
>> So for me, out of the box, sometimes there will be a match and sometimes
>> not. While until v6.1 the code always assumed it should match if that's
>> the
>> same partner_id company, no matter what user selected as the contact.
>> I gave several examples of them in a previous comment without having to
>> search a lot.
>>
>>
>
> Ouch, you are right Raph.... I forgot this...
>
> One time this wrapp method i mentioned before is done....
>
> We(Openerp Sa) must to make a find (*.patner_id) in all addons, and read
> manually when it is taking fiscal or accounting information and change by
> the correct "read" method.
>
> Probably the browse too? i dont know.
>
> Regards.
>
>> IMHO you are not considering this pitfall enough.
>>
>> And again, what is the advantage over adding a contact_id field?
>> You want to be able to use contact_id anywhere because you believe this is
>> better (I don't, I think this predates the reporting and business data
>> integrity). But is there any urgency to try to make this new feature work?
>> Having so many strong indicators regressions will not be detected nor
>> fixed
>> easily, shouldn't we better adopt a conservative stance that is FIRST do a
>> solution that protect us against regressions AND THEN eventually implement
>> the new feature in a next release, while taking all the care to guarantee
>> there is not a bunch of hid...

On 03/26/2013 09:17 PM, Raphaël Valyi - http://www.akretion.com wrote:
> @Fabien, this enable reading the proper data inside the contact record.
>
> But
> 1) how will you decide which fields exactly are copied or not?
> 2) how does it scales across modules adding fields in res.partner, which
> fields will be copied or not?

I tried to answer both questions that in part B of the solution:

  "when writing() on a partner that is an commercial party, all the values of
invoicing/accounting-related fields will be automatically copied to all
descendants that are not commercial party themselves (e.g. pricelist, G/L
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?

> 3) what about all the existing business logic that makes a decision by
> taking some arbitrary foreign key pointing to the res.partner table and
> comparing it with partner_id. What leads you to warranty us with so much
> assurance that the code will always be consistent with the expected
> behavior if partner_id can now randomly be the parent company or any of its
> contacts?

The idea is that there should not be many places in the code where a direct
comparison of partner_id is necessary and where a mismatch of contact vs
company would cause a dangerous or hidden logic error, except in accounting.
Accounting is directly addressed by the proposed solution, and a search for
"if.*partner_id.*=" or "'partner_id'.*'='" (for domains) in the Python code of
addons reveals nothing relevant outside of accounting.

There might be a few cases where a domain in a view or context action needs to
be changed to use "child_of" instead of "=", but those cases should be mostly
usability issues.

> IMHO you are not considering this pitfall enough.

We are considering it quite seriously, but have not found any valid
counter-example so far. The examples that have been mentioned are either not
correct (all accounting examples so far are properly addressed by the solution)
or not specific enough that we can actually verify them.

> 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. 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.

Basically if we introduce the 7.0 model *and* start adding extra partner fields
on...

On 03/26/2013 09:31 PM, Nhomar - Vauxoo wrote:
> Techinically it should be a method called
>
> def _get_fiscal_data(self, .....):
> return {fiscal dict}
>
> And the core overwrite the read method.
>
> def read(....):
> return self._get_fiscal_data(....)

Not exactly. As explained in part B of the solution, there will be a method on
res.partner than any module can inherit to determine the fields that are
managed on the "commercial party" and automatically synchronized on all its
children. It will not affect res.partner.read(), but res.partner.write()! If
only read() was changed the actual data in the database would be incorrect so
search() or JOINs would not work as expected.

So there *will be* a method that your localization can extend to choose the
fields that are synchronized from the parent. That should do the job, shouldn't it?

In any case, it will probably be easier to understand after reading the merge
proposals. Hopefully they should be ready today.

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 ...

I suggest each of you link your branch implementing your solution to this bug. It will be easier for anyone to evaluate each solution.

Hello,

I started coding a patch adding a contact_id at least in the account module, but not finished yet sorry.

Meanwhile, here are some more quick examples of things that won't work as claimed if you keep enabling contacts in partner_id on business documents:

Sale module:
sale/sale_view.xml: <field name="project_id" context="{'partner_id':partner_id, 'default_pricelist_id':pricelist_id, 'default_name':name, 'default_type': 'contract'}" groups="sale.group_analytic_accounting"

So basically this context will automatically create the analytic account (yah project_id is an analytic account ;-) according to the partner_id of the sale order.
That is, you will now create as many analytic accounts as contacts for the same customer on v7. Very smart...

An other quick one:
purchase/stock_view.xml: <field name="purchase_id" domain="[('invoice_method','=','picking')]" context="{'search_default_partner_id':partner_id,'default_partner_id':partner_id, 'default_invoice_method':'picking'}"/>

Here it allows to create an incoming shipment and link it to some existing purchase order with some default filtering.
But now, with v7 contact "innovation", you may totally miss purchase orders related to the right supplier but related to a different contact. You may also fail to look at the parent_id if you selected a contact in the picking instead...

And how would you solve that?

Wouldn't you like to add a "commercial entity" field in these views so that you could use them to pass the right domains and contexts? Then you would need to add that field as a stored field in these business documents.

That is ADDING A FIELD just like are trying to avoid now with all that surrealistic proposition.
So if it's for adding a field: I say take no risk: add that contact_id field instead and keep partner_id untouched just like code consolidated over nearly a decade just expects.

And again, this is just a quick scan in some official addons, there are dozens if not hundreds of such cases when considering the main community modules (localisations anyone?).

So sorry, still not my religion.

We discussed this question at Therp and find to favor the two fields (of type many2one: res.partner) approach. The second field should be non-mandatory but take precedence over the first one (partner_id) if set.

The reasoning is threefold:

This datamodel reflects what you actually want to have. Business documents simply have a relation to two entities: The company a contact/address belong to and the contact itself. Sometimes they happen to be identical, sometimes not, which is not a problem with the two fields approach. Of course, you would implement some smart on_change methods that choose the most likely subpartner or the matching company. You may even hide the second field per default. But those UI considerations don't really matter for advocating the two field approach.

Then also this approach seems to be a lot less intrusive code-wise. Apart from the code Olivier proposes to write, modules dealing with partner_ids have to be adopted to the fact that you're not sure which kind of entity sits in your partner_id. Additionally to _find_commercial_party, you'll also have to provide _find_legal_person and _find_natural person, which the modules have to use.

More important: users should be prevented from entering data like fiscal position, payment terms etc on the partner that is not the legal customer. The idea to duplicate or automatically copy data should be anathema to anybody caring about duplicate data. Problems are bound to occur with people then changing stuff on the wrong partner. Where redundancy exists, in the long, or probably not so long, term, inconsistencies and errors are almost certain to occur.

It would be even more helpful to put the two fields approach into a mixin class, provide some standard on_change methods there and help having a consistent semantics of the different models. This mixin should be used by sale.order, account.invoice etc.

To summarize: Please use two fields pointing to res.partner, one for the legal entity, one for the physical person/location/whatever.

On 03/28/2013 10:21 AM, Holger Brunn (Therp) wrote:
> We discussed this question at Therp and find to favor the two fields (of
> type many2one: res.partner) approach. The second field should be non-
> mandatory but take precedence over the first one (partner_id) if set.

Thanks for your feedback. I'm afraid there's a lot of confusion now on this
topic because many people comment without properly understanding all the details.

For starters the system will not force you to use contacts where you don't want
to use them. It just introduces the fact that contacts can be a valid level of
granularity in most places in OpenERP.

The proposed solution will also take proper measures to ensure that your
accounting and reporting is correct, while giving you the choice of the
granularity level you want to have.

> The reasoning is threefold:
>
> This datamodel reflects what you actually want to have. Business
> documents simply have a relation to two entities: The company a
> contact/address belong to and the contact itself. Sometimes they happen
> to be identical, sometimes not, which is not a problem with the two
> fields approach. Of course, you would implement some smart on_change
> methods that choose the most likely subpartner or the matching company.
> You may even hide the second field per default. But those UI
> considerations don't really matter for advocating the two field
> approach.

A contact is always taken as an entity that belongs to a larger party, and it
will delegate some of its attributes to the larger party when needed (address
and/or accounting settings). This is transparent and means that a contact *is*
the right reference to keep everywhere - it comes with everything you need.

The idea is that for most companies using contacts on business documents will
be very user-friendly: not only for the B2C case, but also for B2B. And there
is no need to duplicate the fields because a contact comes with everything that
is needed.

> Then also this approach seems to be a lot less intrusive code-wise.
> Apart from the code Olivier proposes to write, modules dealing with
> partner_ids have to be adopted to the fact that you're not sure which
> kind of entity sits in your partner_id.

Certainly not, the whole point is that a contact *is* the right level of
granularity in most documents. And since it will come with correct data (incl.
accounting/invoicing), there should be no need to modify any module.

If you don't agree with this, then you don't agree with the fact that contacts
are a valid level of granularity.

In fact the "two-field approach" will need to patch a lot of modules, otherwise
the "contact" will simply be ignored. If users create documents for a contact,
they will expect to be able to find it everywhere under that reference. It
won't be the case unless all search views/list views/reports are modified to
also include the "contact" info. If this is not done the contact field will be
a mere useless decoration - and will actually create the opposite confusion. If
it is done you have a lot of code and duplication of information. And it would
not prevent users from entering payment terms on contacts, etc.

>...

On 03/28/2013 07:01 AM, Raphaël Valyi - http://www.akretion.com wrote:
 > I started coding a patch adding a contact_id at least in the account
 > module, but not finished yet sorry.

In your solution, have you decided on a way to make the contact info available
in all search views, reports, etc? Because if the contact automatically carries
the company info, the opposite is not true. So if your strategy is to force the
`partner_id` field to contain the "commercial party" of the contact, and add a
second `contact_id` field to store the contact, the rest of the system will
still be using `partner_id`. So the contact chosen by the user will disappear
everywhere else. Won't that be rather confusing for the user and make the
contact_id a useless field, defeating the whole purpose of the 7.0 model?

 > Meanwhile, here are some more quick examples of things that won't work
> as claimed if you keep enabling contacts in partner_id on business
> documents:
>
> Sale module: sale/sale_view.xml: <field
> name="project_id" context="{'partner_id':partner_id,
> 'default_pricelist_id':pricelist_id, 'default_name':name, 'default_type':
> 'contract'}" groups="sale.group_analytic_accounting"
>
> So basically this context will automatically create the analytic account
> (yah project_id is an analytic account ;-) according to the partner_id of
> the sale order. That is, you will now create as many analytic accounts as
> contacts for the same customer on v7. Very smart...

This looks like a bug that already existed in previous versions of OpenERP: the
context should probably be corrected to: `'default_partner_id':
partner_invoice_id`, so the analytic account is properly created for the
invoicing partner: either the one you manually choose or the one automatically
chosen by the system based on the partner `type`, as described in Part C.

> purchase/stock_view.xml: <field name="purchase_id"
> domain="[('invoice_method','=','picking')]"
> context="{'search_default_partner_id':partner_id,'default_partner_id':partner_id,
> 'default_invoice_method':'picking'}"/>
>
> Here it allows to create an incoming shipment and link it to some existing
> purchase order with some default filtering. But now, with v7 contact
> "innovation", you may totally miss purchase orders related to the right
> supplier but related to a different contact. You may also fail to look at
> the parent_id if you selected a contact in the picking instead...

That seems the expected behavior when you manually create an incoming shipment
and choose a supplier contact as the Supplier. First, the system will allow you
to link it to a PO from any partner because the domain does not restrict it -
and auto-completion will work. Secondly: if you open the full search view or
try to create a PO on-the-fly the system will simply copy the selected Supplier
in the Supplier field, as expected. You can change it if you want but if you
selected a contact as Supplier it's probably because you meant it - a question
of granularity.
And as a reminder, the system is taking care of creating the appropriate
incoming shipments when you create a purchase order, so ...

On Thu, Mar 28, 2013 at 11:40 AM, Olivier Dony (OpenERP) <
<email address hidden>> wrote:

> On 03/28/2013 07:01 AM, Raphaël Valyi - http://www.akretion.com wrote:
> > I started coding a patch adding a contact_id at least in the account
> > module, but not finished yet sorry.
>
> In your solution, have you decided on a way to make the contact info
> available
> in all search views, reports, etc?

Yes indeed, we should still patch a few things absolutely! You should have
thought to this before enabling selecting contacts everywhere in the wild
in v7 codebase, instead refusing now to fix things beyond the surface just
because it looks as a change now.

BUT:

   1. as for manual search (not existing code logic), searching the name of
   the company will also propose the contacts. Whereas if your partner_id is a
   contact, search the name of a contact doesn't bring the company. So I
   consider it much better partner_id to be the company.
   2. eventually you could make selecting a just contact an opt-in thing:
   business object by business object or using some opt-in context key you
   could reuse in the res.partner search
   3. rationale: in 6.1 and before you could already not select a contact
   for many documents, so if you cannot select a contact in partner_id at
   least it's not a regression: it's just may be the absence of a new feature.
   I claim regressions like that should be avoided at all costs before trying
   to enable new features. A mixin as Holger Brunn suggested would be the
   right abstraction to encaspulate that possible type generalization that
   IMHO should be done case by case after ensuring upfront that the code can
   accept it and that loosing the "commercial entity" key isn't a big deal
   (generally it is) instead of done in the wild in the middle of a claimed
   stable release.

> Because if the contact automatically carries
> the company info, the opposite is not true. So if your strategy is to
> force the
> `partner_id` field to contain the "commercial party" of the contact, and
> add a
> second `contact_id` field to store the contact, the rest of the system will
> still be using `partner_id`. So the contact chosen by the user will
> disappear
> everywhere else.

This sounds all convincing on the surface BUT:

   1. we ALREADY have this problem after that "full contact v7 innovation".
   Because at least you forced payments and account moves to be related to the
   commercial entity instead of the contact (so they already mismatch the
   contact who lead to them).
   2. and more than that: as you see, in many countries, invoicing a
   contact is illegal (Spain Brazil, but I guess there is a gazillon of them).
   So we will also already have a mismatch between contacts and invoice
   partner_id (without any built'in way to carry the invoice contact anymore
   by the way).

> Won't that be rather confusing for the user and make the
>

Sure it's bringing some confusion. But I claim you should have thought to
this before enabling contacts everywhere, not now 100 days after the
release because we, the bad guys, are daring to comply about B2B been
broken in the wild.
I claim this is much better to at le...

One more thing I forgot:

@Olivier, how ca you both claim OpenERP SA will be porting the base_contact module to v7 last week
http://www.openerpsite.com/openerp-7-0-y-localizacion-espanola

AND, at the same time you explain us now that you will copy accounting/financial/fiscal data from the company to all its partners?

So how will a contact ever have two different VAT codes depending on which its companies you are considering?
Is that some quantum magic module?
I'm not a big fan of "heisenbugs" myself.

Come one, let's be honest about all that: OpenERP SA didn't plan it and you are now dealing with the urgency after we discovered the issues. But I claim that the best solution and the simpler isn't just copying data on the surface to hide issues.

err in #21:
 "copy accounting/financial/fiscal data from the company to all its partners?" -> copy accounting/financial/fiscal data from the company to all its contacts?

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 a...

> I can not understand all this big problems and issues on something that apparently is so easy to solve.

Actually, I have the same feeling than you Ana. I can not understand why we have so much confusion and resistance to the change for something that is so easy to solve :)

So, I guess the best is to wait for the development of Olivier (and possibly others), test them and judge based on proposed solutions.

> It's more... we had a solution on previous versions but this is another history and war.

No, the previous solution did not worked perfectly.

In v6.1:

  - No clean solution to sell to persons rather than companies, but also: log a call with a person, assign an issue to a person, ...
  - No clean separation of concepts: partners and addresses --> but usually an address was a contact, not an address
  - No clean address book: the res.partner object was designed for companies but users used it for a mix of individuals and companies due to how it was designed
  - Not easy enough: lambda users did not understood why they had to put a partner and an address on an invoice (and all others documents). I let you test proprietary accounting software, nearly all of them just have one field on the invoice: Customer. (and a lot of users did not even understood what's a partner --> they think it's related to partnership)
  - Not clean logic between all modules using the same objects (res.partner and res.partner.address) with different semantics: sale orders where designed to work with companies, events was designed to work with people
  - base_contact was not good enough

Hi Fabien, thank you for answering but I don't agree in several points of your comments.
> No, the previous solution did not worked perfectly.
It's a subjetive opinion. For most of our customers it did so... let's them decide what they need but Yes... of course, everything can be improved even if it's good enough.

In v6.1:

> - No clean solution to sell to persons rather than companies, but also: log a call with a person, assign an issue to a person, ...
Depending on what you consider a person. At the end a customer is a customer, someone/some company you are going to invoice to or receive invoice from. It doesn't matter so much if it's a company or person. For both of them we need in Spain only Name, VAT, address and fiscal data. Same for both. About relating an issue to a person, usually this person will be related to a company, so, if you set both fields partner_id + contact_id any situation can be solved.

> - No clean separation of concepts: partners and addresses --> but usually an address was a contact, not an address
Address was an address. Contact was a contact. What's the matter with that?

> - No clean address book: the res.partner object was designed for companies but users used it for a mix of individuals and companies due to how it was designed
Address book is Partner several addresses containing several contacts. Again. What's the matter with that? Why is so important think separating individuals and companies? Why should be different thing individual and company when you have got to invoice them. Even one individual could have several addresses and contacts related to him. What is the difference? Name field? I don't understand the point.

> - Not easy enough: lambda users did not understood why they had to put a partner and an address on an invoice (and all others documents). I let you test proprietary accounting software, nearly all of them just have one field on the invoice: Customer. (and a lot of users did not even understood what's a partner --> they think it's related to partnership)
I don't believe it's so difficult understanding the concept. I sincerelly think that now, where everything is mixed, not having different concepts for partner, address and contacts, it's much more difficult trying to define with final users several complex structures. Before was much easier explaining any situation. I know that we will have problems as consultants explaining new aproach to most of our customers.

 > - Not clean logic between all modules using the same objects (res.partner and res.partner.address) with different semantics: sale orders where designed to work with companies, events was designed to work with people
OK. This could be improved, you are right but it was not so complicated since you can relate any master data on any document clearly. Let's say delivery address, related to a partner address or CRM claim, related to a partner contact. Both related to partner who created the document. Both fields are still needed, even on new aproach.

> - base_contact was not good enough
As I said before, anything can be improved always but I was loving base_contact just like it was. Almost ANY complex situation, structure...

Hello,

So I implemented a module attempting to fix the contact data model in OpenERP v7.

Basically, for every OpenERP business object having a partner_id field, it adds a new contact_id field.
Then it override the views so that by default only the contact_id field is shown to the user. In contact_id, the user can select any contact just as in the regular v7. BUT, in the on_change event, the partner_id field is set with the proper related "commercial entity".

Features:
========

1) The partner_id field is really what the code as always been expected, you don't need to sell your soul anymore to the devil by believing blindly unprepared code can cope with such a huge semantic change (contacts in partner_id).

2) As your documents are guaranteed to have a proper commercial entity key, then grouping and relating documents by companies just work again.

3) All documents also have a contact_id key to keep a reference to the contact.

4) You can even search documents both by contacts or by companies.

5 ) There is a new "Advanced Contact Management" security group. If you belong to that group, then you see both contact_id and partner_id in the forms, so you could eventually set a contact from a different company if you want. This could pave the way to some kind of base_contact module in v7.

6) The way I add the contact_id field is extensible. You could extend my decorator to add extra intermediary levels (and security groups) if that's of any use: like contact < regional division < national division < company. Of course all that could be inferred again from the contact, but having it directly in the documents, may ease analysis and relating documents. Well in any case, this is just an idea, as it is, it only adds the contact_id field.

Current Limitations:
=================

1) The contact_id field may not be propagated from a document to another because the official codebase is ignoring contact_id so far. Well, this isn't such a big deal, because you won't need to propagate a contact from a document to another so often. Main use cases could be: CRM to sale order, sale order to invoice and purchase order to invoice. For these simple case, we could easily override the few involved methods specifically to ensure contact_id is passed. In any case, with my module, at least now you have a guarantee that the "commercial entity" is kept between document. That is in any case you can match upon partner_id as before: you may get documents from other contacts, but at least you won't miss any anymore.

2) if you don't belong to the "advanced contact management" group and see only the contact_id field and if some from on_change sets the partner_id field in the form. Then your contact_id field isn't going to be updated at the moment. Suggestions to work around this are welcome. Fortunately, the case may not be common, and again, we could override it specifically.

That's it. I don't claim it's perfect yet. It's a first version. Feedback and suggestions are welcome.

Here is the module:
http://bazaar.launchpad.net/~akretion-team/openobject-addons/akretion_b2b_unfck/files/head:/akretion_b2b_unfck

Best regards.

An other limitation of my module is: currently OpenERP will attempt to send emails to partner_id, that is the company and not its contact. May be the messaging system has similar limitations, I'm not sure.

In any case, I claim that it's much less a problem to send a mail to a company instead of a contact rather than corrupt your business data by mixing arbitrary contact ids among them.

And again, we could override these things specifically to make these mail feature work with the contact again.

I was experimenting if it's possible to override these things from the several involved addons all inside my module, doing something like if self.pool.get('crm.make.sale') not None, then override it to propagate the contact to the sale order. I appreciate any feedback how to do that , thanks.

@odony

Do you have any date as to when your branch implementing your solution would be available for evaluation ?

Thanks.

Hello All.

We are working on analysis for some implementations in V7.0 deeper because
they are so big ones.

We made a first analysis regarding to this, trying to be as precise as i
can in terms of problems, this is now a Aork in Progress but i think it can
be usefull for Oliver to verify things i show there.

We will try this week put analysis like this and regarding to all models,
our most important one "Accounting" is here.

https://www.evernote.com/shard/s158/sh/40828d76-d94a-4f44-bdb5-9c0336f55a52/fe43fe77c401e9f3bdf95982a4b0a878

Thanks MY 2 cents.

2013/3/26 Olivier Dony (OpenERP) <email address hidden>

> Public bug reported:
>
> == Problem Description ==
>
> This issue is an attempt to formalize the various problems detected with
> the res.partner refactoring that took place in OpenERP 7.0. Some of the
> issues have already been discussed on bug 1151947, bug 1155679 and on
> help.openerp.com.
>
> The main problems identified so far:
>
> 1) When a simple contact (type=contact) is selected as the reference
> party for creating a business document (such as the customer on a Sales
> Order), a proper invoicing partner (if any) should be selected among the
> descendants of the "commercial party" to which the contact belongs,
> instead of the contact itself.
>
> 2) Even when a simple contact is used as the invoicing partner for a
> business operation (e.g. manually selected by the user as the invoice
> address on a SO), all invoicing/accounting-related master data must be
> taken from the relevant "commercial party" for that contact. This will
> usually be the parent company.
>
> 3) When editing contacts/addresses, it is currently possible to view and
> edit accounting/invoicing related data, while it should be clear that
> this data is coming from the "related commercial party", usually the
> parent company.
>
> 4) When searching though business documents for a company name, the
> entries that were issued for one of the company's contacts/addresses
> should be found as well.
>
> 5) It has been reported that in some countries it is not permitted to
> issue invoicing documents for a contact, so the name of a relevant
> invoicing must be used instead (Financial Department or parent Company).
>
> 6) In "Analysis" reporting views, result that are grouped by partner
> will not be automatically aggregated at company level.
>
>
> == Proposed Solution==
>
> The rationale for the proposed solution is based on the following points:
> - We think the 7.0 partner model is appropriate and should not be
> considered the cause for these functional/usability problems
> - We think the solution should be mostly handled by the res.partner model
> itself, so that it fixes most modules automatically.
> - We think that in many cases, using a contact/address is the right level
> of granularity, and any reporting based on that is fundamentally correct.
> Invoicing/Accounting is specific for the reasons mentioned above, and
> automatically selecting the proper entity to use should make reporting
> provide the expected result.
>
> Based on this, we propose the following solution. Parts A & B are meant
> to solve the issue of using the right invoicing/accounti...

Copy (with additions) of my comment: https://bugs.launchpad.net/openobject-server/+bug/1151947/comments/22

Basically supporting Therp and Ana Juaristi Olalde (ajuaristio) opinions.
"One address is nothing more than one address. Many2many with all other entities. One same address can be related to any other entity, so including address on partner, not having address separate entity is itself one bad basic db error..."

Partners and products are cornerstones of any business program.
While trying to implement universal model described here
http://www.tdan.com/view-articles/5014/
programs usually becomes too complex to use.

Hierarchy in Partner entity is good for describing complex organizations. Nothing more.
On a second thought, we will be better off without hierarchy in Partner entity.
Let it be separate "relationships" entity capable of describing any type of organization.
Flag 'is_company' can be good enough to distinguish Persons and Organizations.
There is a need for Address as a separate entity and many2many relations.
Let it be generic address with a type and usage that can be easily extended.

Other m2m relations Partners2Partners with relation types can then be implemented as
series of addons adding complexity as needed.

It is easier to make additional module for simple use cases hiding complexity,
than to build complex divergent modules on "sand".

Moving Contacts form partner_address is improvement in 7.0.,
but "not having address separate entity " is not.

There is a need to be clear about when we are talking about:
   1. Efforts to somehow fix 7.0 functional/usability problems
        +1 for: Holger Brunn (Therp)s "The idea to duplicate or automatically copy data should be anathema ..."
                       and two field approach on business documents.
         What about hiding&disabling contacts as childs on partner form, and new objects for addresses and relationships?
   2. What is the roadmap/plan/wishlist for next major release (if any)
       +1 for Ana Juaristi Olalde opinions, and
       Is there any chance to change this point in near future?
          " - We think the 7.0 partner model is appropriate and should not be considered the cause for these functional/usability problems "

Thanks MY 2 cents.
Goran Kliska

I've submitted a pair of related merge proposals for both server and addons to implement the various parts of the solution explained in the description of this bug:

- server: https://code.launchpad.net/~openerp-dev/openobject-server/7.0-fix-contact-company-handling/+merge/157577
- addons: https://code.launchpad.net/~openerp-dev/openobject-addons/7.0-fix-contact-company-handling/+merge/157576

Please read the description of the merge proposals for more details. They also cover the related problems of address synchronization, another area where we need to emulate a set of 'fields.related' towards a parent under some circumstances.

These merge proposals will only be finalized after your tests and feedback, so please take the time to give these branches a test ride with real use cases (you can use runbot.openerp.com for that).

Don't forget that we're not trying to do the same thing as in v6.1: we're trying to provide a simple and user-friendly system for everyone where the most common cases are correct by default, and where dangerous user mistakes are prevented by default as well (less common cases might require more careful config/use, that's fine).

Thanks!

PS: for those who are asking about base_contact for v7 (linking a contact to multiple companies), Fabien already mentioned in comment #8 that a proof-of-concept (definitely not ready to merge) was available on runbot - look for "7.0-base-contact-xal" or go directly to the branches: lp:~openerp-dev/openobject-server/7.0-base-contact-xal and lp:~openerp-dev/openobject-addons/7.0-base-contact-xal This was drafted before the current discussion but the model looks compatible with the solution proposed here.

Hello Olivier,

I'll comment later on the issues that are still largely unfixed after all these proposed changes (that are exactly those I was expecting). But I'll take my time to be the most explicit possible.

Now when you say:
"Don't forget that we're not trying to do the same thing as in v6.1:
we're trying to provide a simple and user-friendly system for everyone"

Did you try my proposal 5 minutes at https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/27
?
Are you implying that their would be any difference with the current 7.0 from a user point of view?
Because frankly I see none (only 1 contact field to fill which can be any kind of contact, still possible to find documents by contacts). Is that perfectly clear for you too?

Hi,

First of all, thank you for asking our feed-back ! I would have loved that you'll have made that before changing all this... But what's done is done..

After testing this on the runbot, I must say that part of the troubles we faced seems solved, but still I get a strange feeling on some points.

Configuration of my test partners:
----------------------------------------------------
  * Camptocamp (is_company : True)
    * Luc Maurer (Use Company Address : True, type: Contact)
    * Claude (Use Company Address : True, type: Contact)
    * Joel (Use Company Address : True, type: Invoice)
    * Guewen (Use Company Address : True, type: Shipping)
  * Camptocamp SAS (is_company: True)
  * Camptocamp Group (is_company: True)

Whats seems good:
------------------------------
 * Multi-level in complexe structure seems to be good (still need a bit of code to display the field parent_id if is_company is checked)

 * Going from the Accounting menu, we can not invoice "Joel" from Camptocamp. If I type "Joel" he founds nobody and suggest to create it. I MUST invoice Camptocamp.

 * Accounting properties are well respected (tax, accounts, fiscal position,..), from Invoice or Sales order (even when Joel is the invoicing contact, fiscal position is ok). We replicate the datas, which if not that good from technical side, but the functional part is ok.

 * Finding partner, contact and so based on company name is easy

 * Read-only on partner form when using "Use Company Address" is good

My questions/remaining troubles:
-----------------------------------------------------
 A) When making a SO, choosing Camptocamp as the Customer, it set Joel as Invoice address and Guewen as shipping one. That means I can invoice Joel from here and not from the accounting menu... That seems strange IMO, what do you think ? If SO can make an invoice for "Joel (Camptocamp)", why I can't invoice Joel as well from the accounting menu... That could be excepted as I asked for "Use company address" on Joel (but even if I remove it, I still can't invoice Joel from accounting menu).

 B) When making a SO to Camptocamp with "invoice from delivery", confirm it, confirm deliver and invoice it => it invoice Camptocamp not "Joel" selected on the offer as the invoicing contact... That is not good. We need to be consistent... I expect to invoice Joel in that case right ?

 C) In the case invoice are related to "Joel (Camptocamp)", the sales turnover for Camptocamp is not correct (from Reporting -> Invoice analysis menu)). I know, you say it is the expected behavior here. If you choose Joel, the turnover belong to him, not Camptocamp. What I want to raise is that it will be true for every relation (not only for analysis). Lets imagine you make various claim to Joel, Guewen and Camptocamp partner... You won't sea them all in the Camptocamp history tab. I mean, this is logical from a technical point of view... But all persons will expect to have somewhere "All trouble related to Camptocamp", "All invoices related to Camptocamp" and so on... this cannot passed through searching "Camptocamp" and having various lines when grouping by...

 D) We still cannot invoice a specific address o...

Hello!

We cannot determine by 100% the impact of such changes, but already have serious issues list:

- data duplication,
- different partner ids for data (not related to invoices only),
- partner_id selection by function (code),
- important community modules relying on old schema,
- reporting related problems (group by partner)
- not tested whole workflow
- undiscovered related bugs

My proposal is:

1. Revert back address model as it was on 6.1.
2. Introduce some base_contact (or whatever proper name) module which installs all necessary interface and view changes while collecting them from user wizard right after installation - e.g. user choose something like "Simplified" or "Advanced" address management right after installation.

This sollution can bear much work to OpenERP SA, but they are responsible for mess they made still.

Normunds
Alistek, Ltd

Joël and Olivier,

My whole point since the beginning is:
1) as Joël said, we need two keys because we absolutely need to be able to consolidate business documents by companies (not just by contacts). I also want to be able to compare my purchase prices by supplier, not by supplier contact (unless I really want to)...
2) Now, if we need two keys: THE ONE EXTRA KEY TO BE ADDED IS THE CONTACT_ID KEY. NOT add a commercial_entity_id key AND SWAP the existing partner_id key from commercial entity to a mere contact without even having planned it properly before the release. . Instead, adding only the contact_id key, leaves partner_id key semantic totally intact, working as expected and makes all these invasive addons changes and the ones you already started to patch the financial parts useless just slowing down/polluting the code while not being generic enough to address all issues.

My 2 cts.

+1 Raphaël

2013/4/9 Raphaël Valyi - http://www.akretion.com <<email address hidden>
>

> Joël and Olivier,
>
> My whole point since the beginning is:
> 1) as Joël said, we need two keys because we absolutely need to be able to
> consolidate business documents by companies (not just by contacts). I also
> want to be able to compare my purchase prices by supplier, not by supplier
> contact (unless I really want to)...
> 2) Now, if we need two keys: THE ONE EXTRA KEY TO BE ADDED IS THE
> CONTACT_ID KEY. NOT add a commercial_entity_id key AND SWAP the existing
> partner_id key from commercial entity to a mere contact without even having
> planned it properly before the release. . Instead, adding only the
> contact_id key, leaves partner_id key semantic totally intact, working as
> expected and makes all these invasive addons changes and the ones you
> already started to patch the financial parts useless just slowing
> down/polluting the code while not being generic enough to address all
> issues.
>
> My 2 cts.
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Addons.
> https://bugs.launchpad.net/bugs/1160365
>
> Title:
> [7.0] incorrect handling of contact/companies for invoicing and
> related purposes
>
> Status in OpenERP Addons (modules):
> In Progress
> Status in OpenERP Server:
> In Progress
>
> Bug description:
> == Problem Description ==
>
> This issue is an attempt to formalize the various problems detected
> with the res.partner refactoring that took place in OpenERP 7.0. Some
> of the issues have already been discussed on bug 1151947, bug 1155679
> and on help.openerp.com.
>
> The main problems identified so far:
>
> 1) When a simple contact (type=contact) is selected as the reference
> party for creating a business document (such as the customer on a
> Sales Order), a proper invoicing partner (if any) should be selected
> among the descendants of the "commercial party" to which the contact
> belongs, instead of the contact itself.
>
> 2) Even when a simple contact is used as the invoicing partner for a
> business operation (e.g. manually selected by the user as the invoice
> address on a SO), all invoicing/accounting-related master data must be
> taken from the relevant "commercial party" for that contact. This will
> usually be the parent company.
>
> 3) When editing contacts/addresses, it is currently possible to view
> and edit accounting/invoicing related data, while it should be clear
> that this data is coming from the "related commercial party", usually
> the parent company.
>
> 4) When searching though business documents for a company name, the
> entries that were issued for one of the company's contacts/addresses
> should be found as well.
>
> 5) It has been reported that in some countries it is not permitted to
> issue invoicing documents for a contact, so the name of a relevant
> invoicing must be used instead (Financial Department or parent
> Company).
>
> 6) In "Analysis" reporting views, result that are grouped by partner
> will not be automatically aggregated at company level.
>
> == Proposed Solution==
>
> The r...

Joel,

> I mean, if we can have more than one in the SO, where is the trouble to
> have various on other objects as well ? It is always like that in other
> software, users are used to that...

I don't think so.

Let's have a look at the most used accounting software in the world.
They all have only one contact/address for the invoicing. They do not
have two fields on each document!

Sometimes, optionally, they have another field for the delivery address.
(which is another purpose)

  - Quickbooks (94.2% of the market share in U.S. !):
    http://www.axonware.ie/catalog/images/quickbooks-invoice.jpg
  - Sage:
http://na.sage.com/sage-payment-solutions/products-services/sage-50-ca-fr/~/media/site/sage%20payment%20solutions/images/landingpages/ssa/ss_2_choose_method_fr.jpg
  - Microsoft Dynamics:

http://dynamicsgphelp.com/wp-content/uploads/2011/06/SalesTransactionEntry.png

If the most used accounting software in the world do that, they can not
all be wrong.

--
Fabien Pinckaers
CEO OpenERP
Chaussée de Namur 40
B-1367 Grand-Rosière
Belgium
Phone: +32.81.81.37.00
Fax: +32.81.73.35.01
Web: http://openerp.com

@Fabien.,

THEY are wrong.... YOU WERE right before.....

Remember this softwares wer made by Monkey Programmers Java, MS Lovers,
this is not OpenERP case.....

For GOD sake dude.... you take off one of the BEST features openerp had....

Sorry for the UPPER case.....

2013/4/9 Fabien (Open ERP) <email address hidden>

> Joel,
>
> > I mean, if we can have more than one in the SO, where is the trouble to
> > have various on other objects as well ? It is always like that in other
> > software, users are used to that...
>
> I don't think so.
>
> Let's have a look at the most used accounting software in the world.
> They all have only one contact/address for the invoicing. They do not
> have two fields on each document!
>
> Sometimes, optionally, they have another field for the delivery address.
> (which is another purpose)
>
> - Quickbooks (94.2% of the market share in U.S. !):
> http://www.axonware.ie/catalog/images/quickbooks-invoice.jpg
> - Sage:
>
> http://na.sage.com/sage-payment-solutions/products-services/sage-50-ca-fr/~/media/site/sage%20payment%20solutions/images/landingpages/ssa/ss_2_choose_method_fr.jpg
> - Microsoft Dynamics:
>
> http://dynamicsgphelp.com/wp-
> content/uploads/2011/06/SalesTransactionEntry.png
>
> If the most used accounting software in the world do that, they can not
> all be wrong.
>
> --
> Fabien Pinckaers
> CEO OpenERP
> Chaussée de Namur 40
> B-1367 Grand-Rosière
> Belgium
> Phone: +32.81.81.37.00
> Fax: +32.81.73.35.01
> Web: http://openerp.com
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Project Group.
> https://bugs.launchpad.net/bugs/1160365
>
> Title:
> [7.0] incorrect handling of contact/companies for invoicing and
> related purposes
>
> Status in OpenERP Addons (modules):
> In Progress
> Status in OpenERP Server:
> In Progress
>
> Bug description:
> == Problem Description ==
>
> This issue is an attempt to formalize the various problems detected
> with the res.partner refactoring that took place in OpenERP 7.0. Some
> of the issues have already been discussed on bug 1151947, bug 1155679
> and on help.openerp.com.
>
> The main problems identified so far:
>
> 1) When a simple contact (type=contact) is selected as the reference
> party for creating a business document (such as the customer on a
> Sales Order), a proper invoicing partner (if any) should be selected
> among the descendants of the "commercial party" to which the contact
> belongs, instead of the contact itself.
>
> 2) Even when a simple contact is used as the invoicing partner for a
> business operation (e.g. manually selected by the user as the invoice
> address on a SO), all invoicing/accounting-related master data must be
> taken from the relevant "commercial party" for that contact. This will
> usually be the parent company.
>
> 3) When editing contacts/addresses, it is currently possible to view
> and edit accounting/invoicing related data, while it should be clear
> that this data is coming from the "related commercial party", usually
> the parent company.
>
> 4) When searching though business documents for a company name, the
> entries that wer...

The Right technical Solution were.

Hide the contact_id, to be used as QuickBooks.... and all is ready, not
change ALL the way to do things,

The correct solution my friend is... Improve your work, not brake it
because the world say another thing....

Be the best is not copy good and bad things, is copy good ones AND change
the world....

Dont give me an example like this, when it is clearly braking A LOT of
features that we already are using,

This is like buy a New car without windows, because majority people close
them in cold enviroments...

Sorry men. Sorry... But IMHO this is one of the worst change i ever seen in
this world.

SAP use not 2 use something like 5 contacts....

Dont compare with QuickBooks Again please, i can list something like 1000
features with OpenERP 6.1 i can make than with This tools you mentioned i
will neve be able to do.

Sorry Again, Sorry, I am now at my 2:00 am in the morning almost crazy
seeing ALL the work i have because you without consult us before decide
sell us QUICK BOOKS..... LOrd..................

2013/4/9 Fabien (Open ERP) <email address hidden>

> Joel,
>
> > I mean, if we can have more than one in the SO, where is the trouble to
> > have various on other objects as well ? It is always like that in other
> > software, users are used to that...
>
> I don't think so.
>
> Let's have a look at the most used accounting software in the world.
> They all have only one contact/address for the invoicing. They do not
> have two fields on each document!
>
> Sometimes, optionally, they have another field for the delivery address.
> (which is another purpose)
>
> - Quickbooks (94.2% of the market share in U.S. !):
> http://www.axonware.ie/catalog/images/quickbooks-invoice.jpg
> - Sage:
>
> http://na.sage.com/sage-payment-solutions/products-services/sage-50-ca-fr/~/media/site/sage%20payment%20solutions/images/landingpages/ssa/ss_2_choose_method_fr.jpg
> - Microsoft Dynamics:
>
> http://dynamicsgphelp.com/wp-
> content/uploads/2011/06/SalesTransactionEntry.png
>
> If the most used accounting software in the world do that, they can not
> all be wrong.
>
> --
> Fabien Pinckaers
> CEO OpenERP
> Chaussée de Namur 40
> B-1367 Grand-Rosière
> Belgium
> Phone: +32.81.81.37.00
> Fax: +32.81.73.35.01
> Web: http://openerp.com
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Project Group.
> https://bugs.launchpad.net/bugs/1160365
>
> Title:
> [7.0] incorrect handling of contact/companies for invoicing and
> related purposes
>
> Status in OpenERP Addons (modules):
> In Progress
> Status in OpenERP Server:
> In Progress
>
> Bug description:
> == Problem Description ==
>
> This issue is an attempt to formalize the various problems detected
> with the res.partner refactoring that took place in OpenERP 7.0. Some
> of the issues have already been discussed on bug 1151947, bug 1155679
> and on help.openerp.com.
>
> The main problems identified so far:
>
> 1) When a simple contact (type=contact) is selected as the reference
> party for creating a business document (such as the customer on a
> Sales Order), a proper invoicing partner (if any) should be selected
> ...

Hello.

I please ask to everybody, test all scenarios, because we need mor eyes
quickly verifying everything.

IMHO, it is better try to include everything in OpenERP solution than
argument bewtween "Two Final Options,"

We found in Vauxoo A LOT of problems with both solutions, but it is not a
matter of argument what is better and what isn't it doesn't help in the end
result, we need to analyse profesionally everything, the problem is there,
stop fight and find solutions please.

Regards.

2013/4/17 Fabien (Open ERP) <email address hidden>

> @nicolas
> > The solution raphael propose is one solution you just don't want to try
> ..
>
> You may have missed this, which is the result of our extensive tests:
> - http://bit.ly/10WPN5S
>
> But that would be great if you can do more tests. It's better to have
> more people that tests all solutions.
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Project Group.
> https://bugs.launchpad.net/bugs/1160365
>
> Title:
> [7.0] incorrect handling of contact/companies for invoicing and
> related purposes
>
> Status in OpenERP Addons (modules):
> In Progress
> Status in OpenERP Server:
> In Progress
>
> Bug description:
> == Problem Description ==
>
> This issue is an attempt to formalize the various problems detected
> with the res.partner refactoring that took place in OpenERP 7.0. Some
> of the issues have already been discussed on bug 1151947, bug 1155679
> and on help.openerp.com.
>
> The main problems identified so far:
>
> 1) When a simple contact (type=contact) is selected as the reference
> party for creating a business document (such as the customer on a
> Sales Order), a proper invoicing partner (if any) should be selected
> among the descendants of the "commercial party" to which the contact
> belongs, instead of the contact itself.
>
> 2) Even when a simple contact is used as the invoicing partner for a
> business operation (e.g. manually selected by the user as the invoice
> address on a SO), all invoicing/accounting-related master data must be
> taken from the relevant "commercial party" for that contact. This will
> usually be the parent company.
>
> 3) When editing contacts/addresses, it is currently possible to view
> and edit accounting/invoicing related data, while it should be clear
> that this data is coming from the "related commercial party", usually
> the parent company.
>
> 4) When searching though business documents for a company name, the
> entries that were issued for one of the company's contacts/addresses
> should be found as well.
>
> 5) It has been reported that in some countries it is not permitted to
> issue invoicing documents for a contact, so the name of a relevant
> invoicing must be used instead (Financial Department or parent
> Company).
>
> 6) In "Analysis" reporting views, result that are grouped by partner
> will not be automatically aggregated at company level.
>
> == Proposed Solution==
>
> The rationale for the proposed solution is based on the following points:
> - We think the 7.0 partner model is appropriate and should not be
> considered the cause for thes...

Scenario 1 with @rvalyi branch : all green, no code duplicate, real semantic

http://goo.gl/4Zrp5

@Nhomar:

- can you report problem you find because I think it is the moment to correct them. For know I think it's no time to fight, test, report, check and propose solution. I will soon post scenario 2 test video :)

Scenario 2 with @rvalyi branch: all green, no code duplicate, real semantic ...

http://goo.gl/IE7fo

note: will test email reception soon, need to have a special real domain for real test :)

@nicolas.

Yes dude.

See the 2 merge proposals, I am puting my specific comments there.

1.-
https://code.launchpad.net/~openerp-dev/openobject-server/7.0-fix-contact-company-handling/+merge/157577
2.-
https://code.launchpad.net/~openerp-dev/openobject-addons/7.0-fix-contact-company-handling/+merge/157576

I strongly think, we must repair the core with OpenERP itself, they are
working on it, lets see what happen.

BTW: Follow the MP.

Regards.

2013/4/17 Nicolas JEUDY <email address hidden>

> @Nhomar:
>
> - can you report problem you find because I think it is the moment to
> correct them. For know I think it's no time to fight, test, report, check
> and propose solution. I will soon post scenario 2 test video :)
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Project Group.
> https://bugs.launchpad.net/bugs/1160365
>
> Title:
> [7.0] incorrect handling of contact/companies for invoicing and
> related purposes
>
> Status in OpenERP Addons (modules):
> In Progress
> Status in OpenERP Server:
> In Progress
>
> Bug description:
> == Problem Description ==
>
> This issue is an attempt to formalize the various problems detected
> with the res.partner refactoring that took place in OpenERP 7.0. Some
> of the issues have already been discussed on bug 1151947, bug 1155679
> and on help.openerp.com.
>
> The main problems identified so far:
>
> 1) When a simple contact (type=contact) is selected as the reference
> party for creating a business document (such as the customer on a
> Sales Order), a proper invoicing partner (if any) should be selected
> among the descendants of the "commercial party" to which the contact
> belongs, instead of the contact itself.
>
> 2) Even when a simple contact is used as the invoicing partner for a
> business operation (e.g. manually selected by the user as the invoice
> address on a SO), all invoicing/accounting-related master data must be
> taken from the relevant "commercial party" for that contact. This will
> usually be the parent company.
>
> 3) When editing contacts/addresses, it is currently possible to view
> and edit accounting/invoicing related data, while it should be clear
> that this data is coming from the "related commercial party", usually
> the parent company.
>
> 4) When searching though business documents for a company name, the
> entries that were issued for one of the company's contacts/addresses
> should be found as well.
>
> 5) It has been reported that in some countries it is not permitted to
> issue invoicing documents for a contact, so the name of a relevant
> invoicing must be used instead (Financial Department or parent
> Company).
>
> 6) In "Analysis" reporting views, result that are grouped by partner
> will not be automatically aggregated at company level.
>
> == Proposed Solution==
>
> The rationale for the proposed solution is based on the following points:
> - We think the 7.0 partner model is appropriate and should not be
> considered the cause for these functional/usability problems
> - We think the solution should be mostly handled by the res.partner
> model itself, ...

Hello folks

I think we have been deviating recently. The first 150 posts of this thread were all asking for the contact_id solution.
Now we have a contact_id solution that is 100% green on OpenERP SA's test suite that was thrown to prove it was buggy. And there is a detail: we do it in 10x less code, without semantic permutation and all its consequences and without data duplication. I mean what's the hell folks?

Videos have been posted to show that we are green, even with the social stuff while our solution aims at preserving the mission critical ERP semantic the code as always been expecting. These videos also show in term of usability for the user, this is exactly the same. There is no such v6.1 come back FUD. There 2 fields in the data model, just like OpenERP SA finally admitted after more than hundreds of posts. But ours are the good ones, that's the difference and it makes a huge difference.

I defended this solution here again in details, please take the time to read:
http://www.slideshare.net/RaphalValyi/openerp-contact-id-solution-to-the-contacts-issue-in-v7

Thanks.

On 04/17/2013 12:31 PM, Luc De Meyer (Noviat) wrote:
> I don't think we should abandon the war since either this issue gets
> fixed by a solution that is acceptable for the community of partners and
> customers or otherwise the community will migrate to other solutions or
> start a new fork. I don't think this is what we want to happen.

I am shocked by that kind of attitude.

It's not a war.
It's not even a fight.
It's not about supporting one person or one company.

I hope people are smart enough to not enter in such a game.

It's just a technical disagreement on how to implement a solution.

Once every year, we have such a bug that create such a big discussion,
some misunderstandings and fears. Its not that much as we process ~6000
bugs per year (<0.1%).

It's normal to have such active discussions as we are all passionate
about what we do and most of the persons on this list do their life on
OpenERP. For me, it's just mean that we do care about OpenERP, a strong
sign of motivation.

Having said that, I may understand that our strict merge proposal/code
review process may frustrate some persons. It's boring as it requires
more effort from everyone: to test, to convince, to develop. But being
strict on accepting only quality code in OpenERP is important for the
future.

We think that what have been proposed may seriously break OpenERP,
that's why we don't want to merge it in the core. But if you want, you
can just do a community module for it. I just hope people listen when
you warned you "YOUR PROPOSITION MAY BREAK THE WHOLE OPENERP".

So, please test deeply and make your own judgment. The different
solutions are independant (Olivier Dony fixed some bugs, Raphael want to
add another layer on top of what Olivier did)

We manage OpenERP like Linus Torvald manages Linux. If Linux dodn't like
something, it will not be pushed into the core, no matter how many
people cry. A lot of people tried to fight against Linux, but at the end
the quality of the kernel is better because of him.

Thanks,

--
Fabien Pinckaers
CEO OpenERP
Chaussée de Namur 40
B-1367 Grand-Rosière
Belgium
Phone: +32.81.81.37.00
Fax: +32.81.73.35.01
Web: http://openerp.com

Hello Fabien,

Many thanks for you answer => I fully agree with you it is not a war and hope it will not be in the futur. BUT it is so important for us, OpenERP Partner, that we can not say YES to everything. We can understand you have some constraints, but you should also accept ours.

There is some features that are MANDATORY for OpenERP and these features are, for me, the minimum we can accept. Without these features, the fork should really be THE alternative.

Camptocamp will migrate from 6.0 to 7.0 in about 2 weeks and if I take the work YOUR team has done, show me that my documents (invoices, CRM, SO, PO, etc...) are completely wrong. In fact YOUR team didn't understood your idea that a partner on v7.0 is no more a company, but a contact..... with the migration YOUR team has made, the partner on my invoice is still the company........ and I do not have any more my contact.....

It is just an example to explain your that on ALL documents that was containing Partner and Contact on v6 HAS to have a partner AND a contact (the best would be to keep the old syntax.... but we can live with partner and commercial entity....).

For me, and for ALL OpenERP Partners, it is the minimum we should have.... not only on the invoice, but on ALL documents.

In fact, I think it was a very good indea to merge into 1 table : partner and contact. BUT the implementation into document is terrific => we still need to have a company and a contact.

Be sure I will not accept the migration without having a company and a contact on my documents...... ;-)

Regards.

Luc Maurer @ Camptocamp

@fabien: thanks for this comment, you're right, this is not a war ! we try
to find solutions, to propose and test, and to say that for us, partner is
different from contact (but can live in same table), and partner is the
only one mandatory key you can have on a business object/document. We can
be wrong and we can have divergence .. that's opensource :)

I've questions, if we (or some other people) want to have clean partner_id
and contact_id semantic différence, do you think we can live together with
the official version ?

Do you think we can have roadmap and documentation of futur new features ?

Now, I think you should have say:

Partners, community members, strong motivated guys, we decide to implement
a new way for managing contact, partner etc .. Here is what we choose at
Openerp:
     - 1 ....
     - 2.....
     - ....

In X month you will have to check all your modules and modify them to be
compatible with the futur version of OpenERP, and you can test it here to
validate your modules, customers instance etc ....

If you want have editor role, think we have to work together and have small
newsletter (technical newsletter, not marketing) to now what will be the
futur ... have discution (not war ;) ). For such a big change, I think we
must prepare our customer with docs, training, migration cost if needed ..
and not after three month of release ?

last, if you decide not to include this branch to openERP (it's your right,
no problem), I think we will have some modules that will be compatible and
some not. Don't know what branch partners prefer to follow, but maybe a
survey / vote can be done just to have an idea ?

My 2 cents,

Nicolas JEUDY

Expert Technique et Fonctionnel Système d'Information
TUXSERVICES

22 rue du seminaire - 25170 Pelousey
e-mail : <email address hidden>
mob. : +33 (0)6 28 95 36 64
http://www.tuxservices.com

2013/4/18 Fabien (Open ERP) <email address hidden>

> On 04/17/2013 12:31 PM, Luc De Meyer (Noviat) wrote:
> > I don't think we should abandon the war since either this issue gets
> > fixed by a solution that is acceptable for the community of partners and
> > customers or otherwise the community will migrate to other solutions or
> > start a new fork. I don't think this is what we want to happen.
>
> I am shocked by that kind of attitude.
>
> It's not a war.
> It's not even a fight.
> It's not about supporting one person or one company.
>
> I hope people are smart enough to not enter in such a game.
>
>
> It's just a technical disagreement on how to implement a solution.
>
>
> Once every year, we have such a bug that create such a big discussion,
> some misunderstandings and fears. Its not that much as we process ~6000
> bugs per year (<0.1%).
>
> It's normal to have such active discussions as we are all passionate
> about what we do and most of the persons on this list do their life on
> OpenERP. For me, it's just mean that we do care about OpenERP, a strong
> sign of motivation.
>
>
> Having said that, I may understand that our strict merge proposal/code
> review process may frustrate some persons. It's boring as it requires
> more effort from everyone: to test, to convince, to develop. But being
> strict on ...

@Luc: True, True, True it's the same with crm_action in 5.0 that are all
converted in opportunity in V6.

business data have semantic, not only field name you rename as you wich.
Migration process should take care of semantic, this is not only a
technical job.

So i go to test more and more the two proposals but luc, I don't know if
you will have your correct migration :)

Nicolas JEUDY

Expert Technique et Fonctionnel Système d'Information
TUXSERVICES

22 rue du seminaire - 25170 Pelousey
e-mail : <email address hidden>
mob. : +33 (0)6 28 95 36 64
http://www.tuxservices.com

2013/4/18 Luc Maurer @ Camptocamp <email address hidden>

> Hello Fabien,
>
> Many thanks for you answer => I fully agree with you it is not a war and
> hope it will not be in the futur. BUT it is so important for us, OpenERP
> Partner, that we can not say YES to everything. We can understand you
> have some constraints, but you should also accept ours.
>
> There is some features that are MANDATORY for OpenERP and these features
> are, for me, the minimum we can accept. Without these features, the fork
> should really be THE alternative.
>
> Camptocamp will migrate from 6.0 to 7.0 in about 2 weeks and if I take
> the work YOUR team has done, show me that my documents (invoices, CRM,
> SO, PO, etc...) are completely wrong. In fact YOUR team didn't
> understood your idea that a partner on v7.0 is no more a company, but a
> contact..... with the migration YOUR team has made, the partner on my
> invoice is still the company........ and I do not have any more my
> contact.....
>
> It is just an example to explain your that on ALL documents that was
> containing Partner and Contact on v6 HAS to have a partner AND a contact
> (the best would be to keep the old syntax.... but we can live with
> partner and commercial entity....).
>
> For me, and for ALL OpenERP Partners, it is the minimum we should
> have.... not only on the invoice, but on ALL documents.
>
> In fact, I think it was a very good indea to merge into 1 table :
> partner and contact. BUT the implementation into document is terrific =>
> we still need to have a company and a contact.
>
> Be sure I will not accept the migration without having a company and a
> contact on my documents...... ;-)
>
> Regards.
>
> Luc Maurer @ Camptocamp
>
> --
> You received this bug notification because you are a member of OpenERP
> Drivers, which is subscribed to OpenERP Server.
> https://bugs.launchpad.net/bugs/1160365
>
> Title:
> [7.0] incorrect handling of contact/companies for invoicing and
> related purposes
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-addons/+bug/1160365/+subscriptions
>

Hi Fabien,

re #223, what the community has collectively expressed here is that we feel that the change *you* propose may break our community addons. Hence the heated debate here and on twitter (and maybe elsewhere too...).

I'll repeat again: Yes it is possible to work with the fix you propose. But it is fundamentally WRONG, because changing the semantic of a database field is like changing the ABI of a library. It is EVIL. Can you seriously imagine Linus Torvalds allowing a semantic change in an API of the linux kernel used by device drivers ? I can't.

Finally, I'm sorry to tell you you do not manage OpenERP the way Linus Torvalds manages Linux. AFAIK no one outside OpenERP SA has commit rights on the main branch, and MP coming from outside OpenERP SA are mostly ignored [1]. There is no public mailing list on which discussions about the evolution and design of things such as res.partner happen (supposedly this should have been openerp-expert-framework, but I don't remember seeing anything close to this last year). There is not even a public roadmap of the changes coming in trunk on which to base these discussions.

[1] to be fair, this has slightly changed since the introduction of the OCB branches.

Regards,

folks,

to make sure there is no misunderstanding, at comment #27 I made POC and that was a POC only. I was sad that this is what was tested in to prove use the contact_id was a wrong idea (despite being supported unanimously outside from OpenERP SA).

So now, we developed the contact_id solution assuming that couldn't e just a module and developed it to a point we consider would be a solution for production.
As I said we are now all green on the original test suite:
https://docs.google.com/spreadsheet/ccc?key=0AhmEftWbRs4sdHJqY2lfeU1HR3hwQm85QS1hQTVMcnc#gid=0
And in fact because we do no semantic permutation, we avoids many of regressions v7 do over v6.1 (at the top of this document).

Again I summed up why we think this solution is better than the current one OpenERP SA was proposing:
http://www.slideshare.net/RaphalValyi/openerp-contact-id-solution-to-the-contacts-issue-in-v7

So make no mistake, the proposed solution that keep semantic aligned, make no data duplication and has 10x less code than the solution proposed by OpenERP SA till now is the following 200 lines of patch (only!):
https://code.launchpad.net/~openerp-community/openobject-server/contact-id-solution-for-v7-contact-management/+merge/159316
https://code.launchpad.net/~openerp-community/openobject-addons/contact-id-solution-for-v7-contact-management

So I ask everybody, including OpenERP SA to reconsider this way of fixing the problem and also suggesting improvements (something that is acknowledged is that we changed some 3 rml reports without changing their sxw source, very soon we will we will do it to ensure no discrepancies even for the ones using openreport conversion).

Regards and thanks for everybody who is helping moving this forward.

Sorry, I made a mistake in the previous links.

So the whole contact_id solution diff can be seen here:

server:
ttps://code.launchpad.net/~openerp-community/openobject-server/contact-id-solution-for-v7-contact-management/+merge/159316
addons:
https://code.launchpad.net/~openerp-community/openobject-addons/contact-id-solution-for-v7-contact-management/+merge/159320

Hope to see convergence of views now.

On Thu, Apr 18, 2013 at 4:40 AM, Fabien (Open ERP) <email address hidden> wrote:

> On 04/17/2013 12:31 PM, Luc De Meyer (Noviat) wrote:
> > I don't think we should abandon the war since either this issue gets
> > fixed by a solution that is acceptable for the community of partners and
> > customers or otherwise the community will migrate to other solutions or
> > start a new fork. I don't think this is what we want to happen.
>
> I am shocked by that kind of attitude.
>
> It's not a war.
> It's not even a fight.
> It's not about supporting one person or one company.
>
> I hope people are smart enough to not enter in such a game.
>
>
> It's just a technical disagreement on how to implement a solution.
>
>
> Once every year, we have such a bug that create such a big discussion,
> some misunderstandings and fears. Its not that much as we process ~6000
> bugs per year (<0.1%).
>
> It's normal to have such active discussions as we are all passionate
> about what we do and most of the persons on this list do their life on
> OpenERP. For me, it's just mean that we do care about OpenERP, a strong
> sign of motivation.
>
>
> Having said that, I may understand that our strict merge proposal/code
> review process may frustrate some persons. It's boring as it requires
> more effort from everyone: to test, to convince, to develop. But being
> strict on accepting only quality code in OpenERP is important for the
> future.
>
> We think that what have been proposed may seriously break OpenERP,
> that's why we don't want to merge it in the core. But if you want, you
> can just do a community module for it. I just hope people listen when
> you warned you "YOUR PROPOSITION MAY BREAK THE WHOLE OPENERP".
>
> So, please test deeply and make your own judgment. The different
> solutions are independant (Olivier Dony fixed some bugs, Raphael want to
> add another layer on top of what Olivier did)
>
>
> We manage OpenERP like Linus Torvald manages Linux. If Linux dodn't like
> something, it will not be pushed into the core, no matter how many
> people cry. A lot of people tried to fight against Linux, but at the end
> the quality of the kernel is better because of him.
>
> Thanks,
>

Thanks Fabien for your answer here, but OpenERP must accept your concept is
not implemented at ALL documents and your team must accept some patches
from community, i believe all people here can gives ideas to Olivier
improve his solutions.

I am very happy to see everybody are discussing and this is good and
OpenERP must catch all ideas and gives a better solution.

Please dont close the door.

Best regards !

>
>
>
> --
> Fabien Pinckaers
> CEO OpenERP
> Chaussée de Namur 40
> B-1367 Grand-Rosière
> Belgium
> Phone: +32.81.81.37.00
> Fax: +32.81.73.35.01
> Web: http://openerp.com
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Addons.
> https://bugs.launchpad.net/bugs/1160365
>
> Title:
> [7.0] incorrect handling of contact/companies for invoicing and
> related purposes
>
> Status in OpenERP Addons (modules):
> In Progress
> Status in OpenERP Server:
> In Progress
>
> Bug description:
> == Problem Description ==
>
> This issue is an attempt to ...

@fabien

What are your criteria for a change between 2 versions to be so huge (in terms of migration effort for the community) that you will not do it ?

To me, with such change on every major release, OpenERP will never be stable and as the number of modules keeps growing, the migration effort for the community will be growing as well. We will arrive at some point where 8.0 will be released and not all interesting modules will be migrated to 7.0. What is your limit ? Migrating a module when you didn't make it yourself is painfull and time-consuming. Do you want to kill older contributing partners and community members ?

I think this is a side effect of your policy to bill for the migration. You have an interest to make that change so big that only your team can migrate a database. The community and customers don't share that interest. You have a development pace that the community and customers doesn't want to follow. Your company should take a deep breath, rely on the partners network to sell OpenERP Enterprise, take the time to move slowly but confidently and work in collaboration with the community members you want to work with. Going fast will lead you nowhere. Instead of investing time on lunch module (I guess it is there because you use it internally), you should focus on important features requested for years. If they asked for it, it means there would be companies switching to OpenERP. More companies use OpenERP, more companies will buy OpenERP Enterprise. We want to create the snowball effect. Today we start from scratch again.

This discussion is just the visible part of the iceberg, and this is not the underlying problem.

Maxime,

> What are your criteria for a change between 2 versions to be so huge (in
> terms of migration effort for the community) that you will not do it ?

I repeat myself:
- the change required to update community modules IS NOT huge

Adapting a community module to the new partner model is peanuts!
Really, please try it.

But I agree that it takes time to port new modules to v7, for plenty of
other reasons: new views, small changes in the processes, ...

> To me, with such change on every major release, OpenERP will never be
> stable and as the number of modules keeps growing, the migration effort
> for the community will be growing as well. We will arrive at some point
> where 8.0 will be released and not all interesting modules will be
> migrated to 7.0. What is your limit ? Migrating a module when you didn't
> make it yourself is painfull and time-consuming. Do you want to kill
> older contributing partners and community members ?

We seriously try to limit changes to the minimum required. But we need a
fair balance between "evolution" and "backward compatibility".

Just imagine this: if we would have applied a "no change" policy,
OpenERP would have been stuck in version 4.2. If we would have done
this, everyone would probably be out of business right now.
  -> To go from v4.2 to v7, we needed to change a lot of things.

Today, our competitors are solid and evolving. Just have a look at
salesforce (a new version every 6 months), new versions of Ms. Dynamics,
and SAP Netweaver...

We need to evolve if we want to survive.

> I think this is a side effect of your policy to bill for the migration.

Yes, we are the evil OpenERP SA:

 - we create bugs to sell more OpenERP Enterprise,
 - we make OpenERP become more complex to sell more trainings,
 - we create huge changes to sell more migrations,
 - we lie on our tests scenario to create noise so that people don't
   notice that we inject bad design in OpenERP,
 - we reject good merge proposals to make people angry... :)

> You have an interest to make that change so big that only your team can
> migrate a database. The community and customers don't share that
> interest.

No, porting a module to v7 is only a few minutes due to this change in
the model. It's not a barrier, it's not even an extra effort compared to
what you get with v7.

> Your company should take a deep breath, rely on
> the partners network to sell OpenERP Enterprise, take the time to move
> slowly but confidently and work in collaboration with the community
> members you want to work with. Going fast will lead you nowhere.

> Instead of investing time on lunch module (I guess it is there because you
>use it internally), you should focus on important features requested for
> years.

Oh yes, I forgot these...

The evil OpenERP SA:

 - waste time developing lunch modules because they like sandwich
 - don't understand the customer need because they never meet customers

Overall, everytime OpenERP SA release a new version:

 - the customer demand decrease
 - the pain to implement OpenERP to customers increase
 - partners loose more and more money on OpenERP every year

People prefer OpenERP v5.0 over v6.0, v6.0 over v6.1, v6.1 ...

I've been taking a considerable amount of time reading almost every single message of this thread, so I'd had no time left to express an opinion, but here it is: I believe both solutions stink, and that's the reason of this blocking situation. Now, I dont have any instant miracle solution so if you don't want to lose any more time with this flamewar, you can stop reading my post just now. Feel free to tell me if I didn't understand some point and I apologize if so.

OpenERP S.A.'s solution is obviously and largely questionnable but it makes sense. OpenERP SA has clearly not anticipated all the consequences of the semantic move, but the community (I'm part of it) seems to really discover or understand this move only these days, and refuses it. So everyone here seems to be right.

Why I don't like partner_id + contact_id :

I really don't like company data duplication in the contacts. I don't like the impact of the community modules. But I don't like the split between contact and partner either, because it's a denial of the fact that even if contact_id field is added, all the partner_id fields in the wild will still be able to represent a contact as well. As a consequence, we won't be able to chose between partner_id and contact_id. In my opinion, the problem is absolutely not solved by adding a contact_id field, because the semantic lies in the res.partner model, not in the name of the field "partner_id" : the partner_id field always points to a res.partner model, which will always represent either a contact or a company anyway. Adding a contact_id doesn't change this fact.
The partner_id + contact_id solution really need more, it would require to split back again the contacts and the companies so that the partner_id field is guaranteed to always be a company. And that would break the b2c possibilities. The res.partner model can be a partner or a contact, this is too late to revert this idea. Adding a contact_id doesn't hurt, but it will never prevent the partner_id from being a contact as well. So what happens if we have a contact in both fields ? This can be prevented with onchange but it means that the datamodel is not consistent and depends on the UI and the javascript. This would allow to write anything though xmlrpc and lead to inconsistencies, or duplicate the onchange behaviour in the xmlrpc dialog. Adding a commercial_entity_id does not hurt and it can be guaranteed to always be a company, since it does not point directly to the res.partner model, but is a function instead. So I'll never have two contacts in partner_id and commercial_entity_id : either two companies, or a company and a contact. So in this case there is no semantic change. The semantic change has already happened, and it lies in the res.partner model. Not in the partner_id field.

Why I don't like partner_id + commercial_entity_id :

The original idea was to invoice either an individual or a company. So the partner_id field would require to be either a an individual (= a contact) or a company. So ok, let's put everything in the same model. This point seems accepted by most people now, but I'm not sure it was a good idea. Putting things in the same model or the same...

Mmh the 3rd paragraph of my previous comment is confusing, the first 2 sentences (data duplication + impact on community modules) was related to the openerp solution, not partner_id + contact_id.

@Fabien
> We seriously try to limit changes to the minimum required. But we need a fair balance between "evolution" and "backward compatibility".
Yes, and that's the problem that on this case the balance between evolution and backward compatibility has been unbalanced

> Today, our competitors are solid and evolving. Just have a look at salesforce (a new version every 6 months), new versions of Ms. Dynamics, and SAP Netweaver... We need to evolve if we want to survive.
My question is if those that you are naming have got one single partner/address/contact table or not. I don't now but I don't think so they are thinking on that because their market is ERP market. Your market, it seems that is going through individual single app market so IMHO it's not ERP market

@maxime
>> Your company should take a deep breath, rely on the partners network to sell OpenERP Enterprise, take the time to move slowly but confidently and work in collaboration with the community members you want to work with. Going fast will lead you nowhere.
I agree on that. Just think the same.

@Fabien
> People prefer OpenERP v5.0 over v6.0, v6.0 over v6.1, v6.1 over v7.
I know you are not going to believe but people was liking more 6.0 over 6.1 but you improved web interface so partners wanted offering that new feature to their new customers but almost all "old" partners we have got still many implementations on 6.0 don't wanting to migrate to 6.1 only for improving Web interface that most of them are not using. They have got their solution build. They are medium-big companies who can't think about migrating their database structure nor trying non stable version or a solution. Be OpenERP, be another one.
If thinks were done right way and there was backward compatibility, without erasing db fields without any sense or remaking valid structures difficult to explain, almost all of them would be on 6.1 and probably paying OPW.
If they feel that core is going to change each 6 month and they are going to suffer a big migration pain each 6 months... they don't need services you are offering because their instance is stable, is working and your new versions are not offering anything attractive enough for migrate. So Opw for them, even having budget to pay or wanting to pay does not apply.

> Did you know that the companies deploying OpenERP in production nearly doubled in Q1 2013 compared to Q4 2012 ?
How can you know that? This is... you have got data about how many small individuals and small companies are registering on your online saas to test, due to your marketing campaing but... How do you know really how many real medium-big companies started up with OpenERP all around the world, what are they demanding for, what version are they installing now Q22013, after 4 months release? How could you have real data about it?

> It does not look like we start from scratch, it looks like the market demand is accelerating and more customers want OpenERP.

sorry but... Customers always liked OpenERP.

> It's always the same thing at every new versions (v5, v6.0, v6.1, v7):
That's true. Why ?

> - first 4 months: partners complain a lot due to changes (why did you do that?) or f...

On Fri, Apr 19, 2013 at 2:48 PM, Christophe Combelles <email address hidden> wrote:

> Mmh the 3rd paragraph of my previous comment is confusing, the first 2
> sentences (data duplication + impact on community modules) was related
> to the openerp solution, not partner_id + contact_id.

Christophe: in any case, I think you didn't get it: the partner_id +
contact_id solution idea is: WE WILL PUT A TYPE on what is a legal entity
or what is a mere contact of a legal entity. And, in the business fields,
we will add these domains OF COURSE to RESTRICT to a legal entity when it's
required on business documents.

The only reason why we didn't do it yet is: supposed somebody already
corrupted his database by mixing contacts in partner_id. We offer him a
chance to still at least try our solution today.
In any case, the way we override write and create, you are guaranteed you
can only write a legal entity into a partner_id, which is what code
expects. Once we make some SQL tools to migrate back and forth between the
two worlds, we may probably add these domains indeed.

Also, in the future, depending on how we emancipate from the main branch
(guaranteed we will not do it in the next 6 months where we will offer us a
chance to come back to the official branch), we will probably add an
"address" type. Today, like on 6.1, addresses and contacts are the same
thing. So contacts cannot reuse addresses and addresses have a birthday and
things like that. It's rarely such a big deal; just create a contact for
every address, it does the job in the vast majority of the time. Now yes,
ideally we "extract" the address concept and make it something some
specific fields can put a restriction on. Then eventually the contact_id of
a purchase.order could be contact BUT NOT a mere address, while the
contact_id of a picking could eventually be just an address (may be).

In any case, having both contacts, addresses and companies in the same
table provides a great advantage:
the contact_id field can allow to select any kind of records in only one
visible field in the interface, so it does make B2C easier. And this is
really FUD to try making believe the contact_id solution is a rejection of
that.

In any case, I think some people already understood what this is all about.
Now it's a matter of organisation.
Unless OpenERP SA considers the contact_id option, here we are going to
maintain that tracking branch to use on v7 as I explained in the slides. We
see we will have all advantages of v7 (definitely a lot) but none of what
we think are shortcomings.

What doesn't destroy you makes you stronger.

Cheers.

On Fri, Apr 19, 2013 at 2:34 PM, Christophe Combelles <email address hidden> wrote:

> I've been taking a considerable amount of time reading almost every
> single message of this thread, so I'd had no time left to express an
> opinion, but here it is: I believe both solutions stink, and that's the
> reason of this blocking situation. Now, I dont have any instant miracle
> solution so if you don't want to lose any more time with this flamewar,
> you can stop reading my post just now. Feel free to tell me if I didn't
> understand some point and I apologize if so.
>
> OpenERP S.A.'s solution is obviously and largely questionnable but it
> makes sense. OpenERP SA has clearly not anticipated all the consequences
> of the semantic move, but the community (I'm part of it) seems to really
> discover or understand this move only these days, and refuses it. So
> everyone here seems to be right.
>
> Why I don't like partner_id + contact_id :
>
> I really don't like company data duplication in the contacts. I don't like
> the impact of the community modules. But I don't like the split between
> contact and partner either, because it's a denial of the fact that even if
> contact_id field is added, all the partner_id fields in the wild will still
> be able to represent a contact as well. As a consequence, we won't be able
> to chose between partner_id and contact_id. In my opinion, the problem is
> absolutely not solved by adding a contact_id field, because the semantic
> lies in the res.partner model, not in the name of the field "partner_id" :
> the partner_id field always points to a res.partner model, which will
> always represent either a contact or a company anyway. Adding a contact_id
> doesn't change this fact.
> The partner_id + contact_id solution really need more, it would require to
> split back again the contacts and the companies so that the partner_id
> field is guaranteed to always be a company. And that would break the b2c
> possibilities. The res.partner model can be a partner or a contact, this is
> too late to revert this idea. Adding a contact_id doesn't hurt, but it will
> never prevent the partner_id from being a contact as well. So what happens
> if we have a contact in both fields ? This can be prevented with onchange
> but it means that the datamodel is not consistent and depends on the UI and
> the javascript. This would allow to write anything though xmlrpc and lead
> to inconsistencies, or duplicate the onchange behaviour in the xmlrpc
> dialog.

Also here I think you are missing another thing Christophes: WE DO override
write and create so YOU CANNOT write a contact into a partner_id field.
Even if you do it with XML/RPC, inside the code via API etc...
But we also set partner_id right inside the on_change, so that just like in
6.1, we have a key to the legal entity right inside the form and we can use
it to filter related records and in other on_changes BEFORE saving the
record, something that even Olivier Dony's solution cannot do because the
commercial_entity_id is computed only when you save the record (aside from
the dramatic semantic permutation of what a partner_id is).

So we don't RELY just on interface and javascript, f...

Following everyone's questions and answers, we improved the rationale explaining the change.

Have a look at this document:
  https://docs.google.com/file/d/0B5BDHVRYo-q5aTBHa0xxNmpLSVE/edit?usp=sharing

Hope it helps better understanding the issue.

Ahhhh sorrrrry,

I didn't understood, this is clear now, thanks.
sarcasms.

All right,

So folks, in any case, I think OpenERP SA has a solution many people here
disagree with. But open source is fantastic, even if you do not agree on
everything, you can still work together on things we agree with, that is
the social and dynamic aspect of it.

So personally, I'm in favor of stopping the OpenERP bashing because no
matter the solution we choose it's still our flagship ERP.

So, as Fabien said, if we agree on many things but not on everything it
doesn't matter so much. And even if we disagree with that change, we thanks
OpenERP SA very much for all the great work they did for v7 like the
gorgeous web client and merging a dozen of our branches since we went to
Belgium last summer.

So everybody can choose between the 2 solutions, this is the great thing
about open source, and I'm pretty sure we will still find many synergies
between the two ways of fixing the issue. As for here we have our solution
and with some advanced bzr or git management we will be able to live with
it and live with it perfectly well even (else we would stick on 6.1, that's
not the case, we will be happily working on 7.0 with that patch).

So, may be we can end up the war about this issue. People who prefer
maintaining the partner_id semantic are welcome to help maintaining our
branch (we will give more clue in the next days where the branch will be
set and how it will work). People who prefer the new semantic and
denomalizing data instead are welcome in OpenERP SA's branch. And I'm sure
plenty of collaboration will happen between the two branches and the
web-client which isn't even impacted. I'm pretty sure only 5% of the
commits won't be automatically applicable because of this difference, just
like there is the OCB tracking branch, I'm sure this is something we can
perfectly handle with a little organization.

Thank you to all who gave their ideas so far and sorry if I have been a bit
rude about the issue. I really would have preferred we didn't have to start
a branch, but no that this is over, let's end that war and move this
forward, the way everybody thinks is better.

Regards.

Thanks to the test feedback received in this discussion and on the merge proposals, many important improvements were made to the solutions. Among others:
 - display name of contacts was changed to "Company, Contact" to make very obvious that company is selected as well
 - ordering of partners in search results, group by, auto-completion, etc. was changed to make it match the display names. This means that when the user wants to do reporting by "Company" the information is readily available even if the document granularity is by Contact, since all the aggregated Contacts are right next to the Company)
 - fixed many remaining views that were not allowing to search on a Company and its Contacts at the same time (child_of operator)
 - a warning message is now displayed when you try to change the company of an already existing B2B contact
 - .. plus many other smaller things, see also the merge proposal descriptions and comments for more details...

As a result, most remaining blocking points are either solved or mitigated, and it is time to merge these branches in the stable series, especially given the severity of the bug in 7.0 currently and the time that was already spent on it.
Further smaller specific issues may be discussed in other bug reports in the future.

The corrections were merged at the following revisions:
 - server 7.0: rev 4946 rev-id: <email address hidden>
 - addons 7.0: rev 9043 rev-id: <email address hidden>

The next step is to finish reviewing and merging the 7.0 `base_contact` module for those who frequently deal with contacts working for several companies at the same time.

Thanks again to everyone for your patience, your feedback and the time you spent testing the various cases!

Hello.

I have some comments about this MP already done.

First.

THe copy method incorrect IMHO it brake all Database management rules in the world, it remember me when we repair systems in Cobol,

Second, How After +200 messages and the MP marked yet as Need Fixing, you autocraticly merge, I think this is a proof of the sum of all my fears...

I even dont know where put my bugs friends, Everything will be really better when instead make patches to hide serious data structure errors you answer things like linux torvals make: https://lkml.org/lkml/2012/12/23/75

IMHO this approach as it is solve several leaks of feature but the MOST IMPORTANT dont.

https://www.dropbox.com/s/gtoh87ehamwjltu/BUGS.pdf

"Data inconcistency."

NO COPY DATA PLEASE PLEASE PLEASE

Regards.

In conclusion i think we must mature this problem more, IMHO 1 week and 200 message is not enought.

IOH.... When we will make public the policies inside OpenERP in terms of technical and functional approach, because It is really tired guess....

Pleas help me dudes...

My Status:

1.- I understand the model, and it is fine, i will use it.
2.- I dont understand why the final solution was copy data, it is so much confusing....

Dear All,

I just had now a very interesting phone call with Fabien and I can confirm that all important issues that really matter for the community will be fullfilled by OpenERP.

Until now, there were actually 3 main concerns :

1. The change of the semantic (Partner/Commercial Entity vs Partner/Contact)
2. The "group by" was not consistent between objects => need to have 2 fields : company and contact
3. The need to have a hierachical search and filter based on the company AND a contact (for instance: I am on Camptocamp SA and I need to have the list of SO sent to Camptocamp SA, to Camptocamp Luc, and to Camptocamp Joel)

Concerning the above issues, Fabien confirms that they will be treated by the end of the week, as follows :

Issue 1. The semantic will remain as Partner / Commercial Entity => Ok, I know it's a shame, but we should accept it since with v7.0, we actually have to change all modules anyway => I hope such a big change will not occur again in the future, especially following a release date.

Issue 2. OpenERP will add 2 levels of "group by" : one for Partner (being, the Contact) and one for Commercial Entity (being the Company) for documents which really require them :
    * it will be a field related field / read-only / store = true
    * it will be done on modules that users can install -or not-
    * the following objects will have a double "group by" (partner + commercial entity) : SO, PO, Invoice In, Invoice Out, Analytic account, Project, Opportunity, Shipping
    * if necessary, the community can create more modules to add the double "group by" feature on other documents

Issue 3. Hierachical search and filter is already available => if not available somewhere in the tool, it will be corrected by OpenERP

Excepted the change of semantic, OpenERP has therefore accepted the resolution of the above issues and has taken into account the needs of the OpenERP community.

I think we now have a win-win situation which encourages us all to resume our work on a stable basis.

I would like to thank all the actors involved in this long and interesting discussion which led to a positive issue for all.

Best regards,

Luc Maurer

It Sound great,

Just an Issue to discuss, IMHO the copy data for some fields, is one of the
biggest one, but I think it has solution too, what about this specific
issue?

Thanks everybody.

Regards.

2013/4/22 Luc Maurer @ Camptocamp <email address hidden>

> Dear All,
>
> I just had now a very interesting phone call with Fabien and I can
> confirm that all important issues that really matter for the community
> will be fullfilled by OpenERP.
>
> Until now, there were actually 3 main concerns :
>
> 1. The change of the semantic (Partner/Commercial Entity vs
> Partner/Contact)
> 2. The "group by" was not consistent between objects => need to have 2
> fields : company and contact
> 3. The need to have a hierachical search and filter based on the company
> AND a contact (for instance: I am on Camptocamp SA and I need to have the
> list of SO sent to Camptocamp SA, to Camptocamp Luc, and to Camptocamp Joel)
>
> Concerning the above issues, Fabien confirms that they will be treated
> by the end of the week, as follows :
>
> Issue 1. The semantic will remain as Partner / Commercial Entity => Ok,
> I know it's a shame, but we should accept it since with v7.0, we
> actually have to change all modules anyway => I hope such a big change
> will not occur again in the future, especially following a release date.
>
> Issue 2. OpenERP will add 2 levels of "group by" : one for Partner (being,
> the Contact) and one for Commercial Entity (being the Company) for
> documents which really require them :
> * it will be a field related field / read-only / store = true
> * it will be done on modules that users can install -or not-
> * the following objects will have a double "group by" (partner +
> commercial entity) : SO, PO, Invoice In, Invoice Out, Analytic account,
> Project, Opportunity, Shipping
> * if necessary, the community can create more modules to add the
> double "group by" feature on other documents
>
> Issue 3. Hierachical search and filter is already available => if not
> available somewhere in the tool, it will be corrected by OpenERP
>
> Excepted the change of semantic, OpenERP has therefore accepted the
> resolution of the above issues and has taken into account the needs of
> the OpenERP community.
>
> I think we now have a win-win situation which encourages us all to
> resume our work on a stable basis.
>
> I would like to thank all the actors involved in this long and
> interesting discussion which led to a positive issue for all.
>
> Best regards,
>
> Luc Maurer
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Project Group.
> https://bugs.launchpad.net/bugs/1160365
>
> Title:
> [7.0] incorrect handling of contact/companies for invoicing and
> related purposes
>
> Status in OpenERP Addons (modules):
> Fix Released
> Status in OpenERP Server:
> Fix Released
>
> Bug description:
> == Problem Description ==
>
> This issue is an attempt to formalize the various problems detected
> with the res.partner refactoring that took place in OpenERP 7.0. Some
> of the issues have already been discussed on bug 1151947, bug 1155679
> and on help.openerp.com.
>
> The main problems...

I followed this discussion now for a long time but i still can not see how to manage a simple case like this:

Company A (e.g. located in Germany)
     Company A Office (e.g. located in Austria)
         Contact A working in The Vienna Office

So the "Company A Office in Austria" is no company and also no person ... BUT "Contact A" should get it's address information from "Company A Office in Vienna" which is only possible if i set this office to "is company" but then i can no longer link the office in vienna to "Company A"

What would be the correct handling of such a case in OpenERP 7.0 with the new "standard" introduced?!?

How should "Offices" or "Shops" be handled?

Thanks @Luc for your comment, the problems at least what we found i read will solved.
Just a Q: when you say:

>> * it will be done on modules that users can install -or not-
>> * the following objects will have a double "group by" (partner + commercial entity) : SO, PO, Invoice In, Invoice Out, Analytic account, Project, Opportunity, Shipping

It means will be another module, not in the core ?

Please clarify it i misunderstood this.

Best Regards,

On 04/24/2013 01:37 PM, Michael Karrer wrote:
> I followed this discussion now for a long time but i still can not see
> how to manage a simple case like this:
>
> Company A (e.g. located in Germany)
> Company A Office (e.g. located in Austria)
> Contact A working in The Vienna Office
>

The data model supports it, but the user interface discourages it currently.
Right now you can obtain this result in the interface by temporarily setting
"Company A Office" as a company while adding "Contact A". The Contacts tab will
remain visible afterwards because it won't be empty.

This is clearly bad on a usability point of view, and this is what bug 1151947
is about (proper solution yet to be found).

PS: you can also have multiple companies in the same hierarchy in a similar
manner: be sure to set the parent company on the subsidiary company before
checking the "is_company" flag, and the parent company will remain visible
after checking the "is_company" flag.

On 04/24/2013 02:28 PM, Cristian Salamea (Gnuthink) wrote:
> It means will be another module, not in the core ?

It will be done via a few small modules to be added to the official 7.0 addons

@odo important for us

Will this solution work in a Multicompany Environment ?
Will the search work nice, without messages ?
What about the record rules ?

Hello,

FYI, OpenERP has made an MP of the module base contact for the version 7.0. The MP can be followed and reviewed here:
https://code.launchpad.net/~openerp-dev/openobject-addons/7.0-base-contact-xal/+merge/192129

kr,
J-E