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

[Olivier Dony (Odoo)]

== 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 cannot be easily 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.

More details on the rationale: http://bit.ly/118HrZ0

Based on this, we propose the following solution. Parts A & B are meant to solve the issue of using the right invoicing/accounting data at all times (issues 2 & 3 mainly), while parts C, D & E are meant to improve the selection of invoicing entities and the related reporting (issues 1, 4, 5 & 6):

A) Let the "commercial party" for a partner be the person or company that is used as reference for all invoicing/accounting matters. The "commercial party" is computed as: the first parent that is marked as a company (is_company is checked) or is the root of the hierarchy if there is no company. It can be the partner itself if it's a company or if it has no parent.

B) The relevant invoicing/accounting data will only be editable on an "commercial party", and all contacts/addresses that are descendants of an "commercial party" will inherit those settings. This will be done as follows:
- when a partner is not an commercial party, the form view will be modified: the Accounting tab and the Invoicing section of the Sales&Purchases tab will be replaced by a note that says something like "Invoicing settings are controlled on <link to commercial party>".
- 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.
- when changing the parent of a partner causes a change of "commercial party", the same fields will be copied

C) When a contact/address is selected as the reference for a business document (SO/PO), the system should automatically select appropriate invoicing and delivery parties from the relevant "commercial party". This is the responsibility of the res.partner.address_get() method (legacy name for backwards-compatibility), and it must be adapted for the new model.
The new algorithm should search in the whole hierarchy of the partner, stopping at the parent "commercial party", as defined in A. This will be used automatically by the on_change triggers on SO/PO/etc, and should ensure that the proper invoicing and delivery partners are always selected.

D) The res.partner.address_get() method considers the partner type "default" as a wildcard, so any partner with type "default" is seen as a match for any requested type. This is correct but unfortunately "default" is the default value, which would stop the lookup described in C at the first step. The "default type" for a partner will be changed to "contact", so that unless otherwise specified a simple contact cannot be used as "invoicing partner" or "delivery partner", unless it is itself a "commercial party".
Note: even if a simple contact has type "default" or "invoicing", the accounting/invoicing settings would still come from the relevant "commercial party". It will simply be seen as a possible choice for the "invoice partner" (e.g. the partner_invoice_id field on a SO)

E) The search view of the main business documents will use the "child_of" operator when matching contacts/partners. For example all Sales Orders issued to any contact from Agrolait will be found when searching for "Partner: Agrolait".

F) (Already implemented in 7.0) When booking journal entries for any partner, the system always links them to the "commercial party" related to the partner (the first parent company or root partner). This makes sure that reporting and reconciling Journal entries will always work properly.

G) The order of Partner records will be modified so that a Company always comes right before its contacts, in a way that matches the display labels. The display label of contacts will be changed to "Company, Contact" in order to make very clear that selecting it includes selecting the Company (contact always acts on behalf of Company).
This will ensure that all search results, including auto-completion of partner names and "group by" views will always be consistent and have all the company documents next to each other.

H) As a special case to the above, an extra module "account_report_company" will be added in the official 7.0 addons in order to add an explicit "Company" granularity in the Invoice list and Invoice Analysis (by adding a denormalized hidden field used for reporting only). We may add such a module for others objects where a group_by feature is required on commercial_id.

== How does the solution solve the issues ==

Let's address the issues one by one:

1) When selecting a contact as the Customer for a Sales Order, a proper "invoice address" and "delivery address" will now be automatically selected, thanks to C & D.

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.

3) Directly addressed by B.

4) Directly addressed by E.

5) Thanks to C & D, an appropriate "invoicing partner" should always be automatically set on SO/PO, in B2C and in B2B cases. So if you want "Agrolait" to be displayed on all invoices that corresponds to SOs issued for "Sylvie Lelitre (Agrolait)", just make sure that "Sylvie Lelite" does not have "invoice" or "default" type, but has type "contact" instead (which will be the default).

6) Due to C, D & H, an appropriate invoicing partner should always be selected on all invoices, regardless of who what the contact to which the SO/PO was issued, and the Company level of granularity will be available in Invoice reporting.

There will be other cases where the contact granularity appears (e.g when grouping Sales Orders on Customer), but this expected and correct. In general the same contact will appear for most documents related to the same commercial party.

For all other case, such as domains, contexts, etc., contacts should be a valid level of granularity, keeping in mind the major use cases: B2B with 2 levels of hierarchy: company and contacts, and B2C with 1 level (normal case) or 2 levels of hierarchy (ecommerce/webshops with multiple addresses for each customer)

And when a "Company" level of granularity is desired, part G of the solution ensures that the results are already grouped by Company (all related rows next to each other), making sure the data is easy to find and aggregate.

== Further refinements ==

In trunk some extra things could be planned to further improve some aspects, such as:
- the "commercial party" field could become a stored function field on res.partner, so that it becomes very easy to add related fields on any document - making reporting per company even easier.
- other suggestions welcome

[Olivier Dony (Odoo) (odo-openerp)]

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.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

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

[Olivier Dony (Odoo) (odo-openerp)]

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

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

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

[Olivier Dony (Odoo) (odo-openerp)]

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.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

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

[Sébastien BEAU - http://www.akretion.com (sebastien.beau)]

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

[Fabien (Open ERP) (fp-tinyerp)]

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

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

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

[Nhomar - Vauxoo (nhomar)]

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

[Nhomar - Vauxoo (nhomar)]

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

[Nhomar - Vauxoo (nhomar)]

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

[Olivier Dony (Odoo) (odo-openerp)]

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

[Olivier Dony (Odoo) (odo-openerp)]

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.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

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

[Maxime Chambreuil (http://www.savoirfairelinux.com) (max3903)]

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

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

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.

[Holger Brunn (Therp) (hbrunn)]

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.

[Olivier Dony (Odoo) (odo-openerp)]

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.

>...

[Olivier Dony (Odoo) (odo-openerp)]

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

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

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

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

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.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

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?

[Ana Juaristi Olalde (ajuaristio)]

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

[Fabien (Open ERP) (fp-tinyerp)]

> 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

[Ana Juaristi Olalde (ajuaristio)]

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

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

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.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

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.

[Maxime Chambreuil (http://www.savoirfairelinux.com) (max3903)]

@odony

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

Thanks.

[Nhomar - Vauxoo (nhomar)]

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

[Goran Kliska (gkliska)]

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

[Olivier Dony (Odoo) (odo-openerp)]

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.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

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?

[Joël Grand-Guillaume @ camptocamp (jgrandguillaume-c2c)]

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

[Normunds (Alistek) (3pm)]

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

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

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.

[Ana Juaristi Olalde (ajuaristio)]

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

[Fabien (Open ERP) (fp-tinyerp)]

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: [phone]
Fax: [phone]
Web: http://openerp.com

[Nhomar - Vauxoo (nhomar)]

@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: [phone]
> Fax: [phone]
> 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...

[Nhomar - Vauxoo (nhomar)]

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: [phone]
> Fax: [phone]
> 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
> ...

[Ana Juaristi Olalde (ajuaristio)]

+1 Nhomar!!

2013/4/9 Nhomar - Vauxoo <email address hidden>

> @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: [phone]
> > Fax: [phone]
> > 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/invoi...

[Stefan Rijnhart (Opener) (stefan-opener)]

Raphaël's last comment summarizes the correct solution. Without an explicit link between business documents and the company partner, OpenERP makes pretty basic reporting such as grouping sales orders by company partners next to impossible using only official modules. There would be a common need for an additional field for the 'commercial entity', which is doable in custom modules but which would effectively swap the semantics between partner_id and contact_address_id in OpenERP < 7.0 and partner_id and commercial_entity_id in OpenERP 7.0 and up. This is an unnecessary and damaging change that is going to cause many regressions in many official and community modules.

By furthermore copying the relevant data from the company parter to its contacts OpenERP is making a dangerous move just to try and maintain data integrity, which would not be necessary when applying the two fields approach.

@Fabien I yet have to hear approval for your approach from any established OpenERP partner or other stakeholders. If the partners that do speak up all disapprove, they can not all be wrong.

[Nhomar - Vauxoo (nhomar)]

And Now...

My friend is so funny you lose the fight, with your own argument, and i think you must rectify, or explain us, how do i make this approach.

The SAGE thing you show:

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

See you have 2 relations with what we have now called "Res Partner"

Client:
Address Expedition :

We need Exactly this in V7.0 how do we solve that without contact_id?

Sorry dude, if you know ALL the work it represent in our 3 localizations and in our 4 parallel deployments, you should feel like me.

I hope you think better the situation and the solution.

Important:

This __are__ not computed fields, the must be coded and saved....

And from an accounting Point of View, we need both references in account move line, exactly as we had before __or better__.....

Help me to see your point my friend Pleaseeee.!!!

Regards.

[Guewen Baconnier @ Camptocamp (gbaconnier-c2c)]

On Tue, Apr 9, 2013 at 9:41 AM, Fabien (Open ERP) <email address hidden> wrote:

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

Having 1 field displayed on the GUI does not means that you do not have 2
fields stored.
Your screenshots have neither no indication if they allow to mix partners
and contacts.

If you read correctly the Raphaël's posts, you will see that he does not
say that you need to display 2 fields. You can still display only 1.
But we have to ensure that the partner_id is always a partner and not
sometimes a partner and sometimes a contact.

[Nhomar - Vauxoo (nhomar)]

gewen, even i think it is more complicated.

We lost an important feature.

In the past you invoice to partners, and set the fiscal address (right ?)

And you had a Tree structure of partners con consolidate some thing (this
structure didn't make anything in the past, but data was there)

Now,

We lost several Fiscal Addresses for a partner.

And

The tree Structure.

What happen with our 100% of customers that use this feature for:

Make Reports?.
Make Electronic Invoices?.

I think the new approach, take off several IMPORTANT data estructures
issues than will make impossible all our migration process.

AND, we lost a lot of functionalities, that are ready managed in older
versions,

What i can see is that Fabien is pushing to just one way, looks like
QuickBooks.!

People of R&D did you almost made a Matrix if impact of this change?

I am so so so afraid and Raphael was right, sorry! we have a serious issue
here.

I find 3 problems per hour even with Odony solution proposed.

2013/4/9 Guewen Baconnier @ Camptocamp <email address hidden>

> On Tue, Apr 9, 2013 at 9:41 AM, Fabien (Open ERP) <email address hidden>
> wrote:
>
> >
> > 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.
>
>
> Having 1 field displayed on the GUI does not means that you do not have 2
> fields stored.
> Your screenshots have neither no indication if they allow to mix partners
> and contacts.
>
> If you read correctly the Raphaël's posts, you will see that he does not
> say that you need to display 2 fields. You can still display only 1.
> But we have to ensure that the partner_id is always a partner and not
> sometimes a partner and sometimes a contact.
>
> --
> 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
>...

[Alexandre Fayolle - camptocamp (alexandre-fayolle-c2c)]

Re Fabien comment #38: a screen shot is not a data model.

If you want to read about the Microsoft Dynamics data model for customers, please read the technical documentation. Starting point is http://msdn.microsoft.com/en-us/library/gg309704.aspx You will see an "Account" entity, a "Contact" entity, a "CustomerAddress" entity. I'm pretty certain similar concepts apply to Sage and Quickbook.

I'm all in favor of having a nice GUI which makes it simple for the end user to make the correct decision, abstracts the gruesome details of the data model. But please, please, please, don't enforce on your partner a data model imagined after the GUI of your competitors.

[Nhomar - Vauxoo (nhomar)]

+1 alexandre.... +1 I think EXACTLY in the same way.

Improve useability is NOT change your data model, is improve the view part.

regards.

2013/4/9 Alexandre Fayolle - camptocamp <email address hidden>

> Re Fabien comment #38: a screen shot is not a data model.
>
> If you want to read about the Microsoft Dynamics data model for
> customers, please read the technical documentation. Starting point is
> http://msdn.microsoft.com/en-us/library/gg309704.aspx You will see an
> "Account" entity, a "Contact" entity, a "CustomerAddress" entity. I'm
> pretty certain similar concepts apply to Sage and Quickbook.
>
> I'm all in favor of having a nice GUI which makes it simple for the end
> user to make the correct decision, abstracts the gruesome details of the
> data model. But please, please, please, don't enforce on your partner a
> data model imagined after the GUI of your competitors.
>
> --
> 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 appro...

[Guewen Baconnier @ Camptocamp (gbaconnier-c2c)]

@Nhomar:

Fore sure, the invoice needs a contact_id and a partner_id.
It does not means that they have both to be displayed (partner_id can be hidden and set from the contact_id).
However, the partner_id must always be a partner and not a contact. So we can safely rely on the partner_id field for grouping, analysises, links between documents...

[Nhomar - Vauxoo (nhomar)]

2013/4/9 Guewen Baconnier @ Camptocamp <email address hidden>

> @Nhomar:
>
> Fore sure, the invoice needs a contact_id and a partner_id.
> It does not means that they have both to be displayed (partner_id can be
> hidden and set from the contact_id).
> However, the partner_id must always be a partner and not a contact. So we
> can safely rely on the partner_id field for grouping, analysises, links
> between documents...
>

Yes agreed...

FYI... I am uploading videos with issues found in the odony's solution.

on the MP, i think the will give us a visual part with problems.

Regards.

>
> --
> 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, so that it fixes most modules automatically.
> - We think that in many cases, using a contact/address is the right
> level of granu...

[Fabien (Open ERP) (fp-tinyerp)]

On 04/09/2013 01:19 AM, Raphaël Valyi - http://www.akretion.com wrote:
> 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)...

That's probably the biggest misunderstanding and the reason why we are
not aligned with the best solution.

If you read carefully the proposition of Olivier:

  - We do not plan to allow invoicing to contacts (in the meaning of
    the person who purchased, or a contact person)
  - We allow invoicing ONLY on "Valid Invoicing Entities"

Be sure you understood the two lines above as it's the biggest
misunderstanding in all our discussions.

That's what Olivier calls the valid level of granularity for invoicing
operations.

With the default configuration:

  - The "Valid Invoicing Entity" is the company itself (Camptocamp),
    not the person (Joël, Camptocamp)
  - So, All invoices will be entitled to Camptocamp, not Joël of
    Camptocamp in the default configuration. Whether it comes from
    a sale order or a manual invoice, the behaviour must be the same.
    Invoices are only entitled to Camptocamp by default.

The great improvement with the v7 approach is that we are also able to
manage hierarchies of partners. (we had hierarchies in v6.1, but it was
not used anywhere, so not useful at all)

So, if you want to define hierarchies of companies:

  - Camptocamp Group [is company]
      - Camptocamp Switzerland [is company]
          - Joël
      - Camptocamp France [is company]
          - Marc
          - Cécile, Accounting Department

With Olivier's proposition, by default, OpenERP allows invcoing to C2C
Group, C2C Switzerland, C2C France. Not to the 3 others contacts. This
is the expected behaviour.

But, if the user wants (only if he explicitly configure OpenERP to allow
it), he can also say that "Accounting Department" is a "Valid Invoicing
Entity" by setting it's address type to 'Invoicing'. (which is not the
default).

In this case, we think that the "Valid Invoicing Entity" is the right
level of granularity for most reporting.

Please note also that there is usually only one "Valid Invoicing Entity"
per company. So all invoices to Camptocamp France will be entitled to
"Camptocamp France, Accounting Departement".

You will not have problems of several lines in your group_by reports,
unless you manually decide to have two "Valid Invoicing Entities" for
the same company AND you create a manual invoice for the other. (which
is a rare situation and, if you do so, you probably expect this level of
granularity in your invoices and invoice reports)

Several notes to answer others confusions:

  - We do agree that adding a partner_id field on the object for the
    legal entity (not on the view) linking to the main company is a
    good improvement. It's even in our proposition. (read Olivier's
    proposal)

  - But for the future version because: according to my explanation
    above, the "Valid Invoicing Entity" is the right level of
    granularity AND we prefer to respect our ...

[Fabien (Open ERP) (fp-tinyerp)]

On 04/09/2013 10:19 AM, Stefan Rijnhart (Therp) wrote:
> @Fabien I yet have to hear approval for your approach from any
> established OpenERP partner or other stakeholders. If the partners that
> do speak up all disapprove, they can not all be wrong.

Yes and no.

No: This reminds me the GTK discussions; everyone wanted to maintain
GTK, fork, stay on v6.1, ... At the end, focusing on one clean web
client was one of the most important move OpenERP did in the pasts months.

Yes: This means we have to bring a big attention on the issue. We have
to understand everyone's argument, evaluate all proposed solutions and
find the best ones. And that's what we are doing.

We are just not convinced by proposed arguments and we think there have
been a lot of misunderstandings/confusions/noise on the issue. Not
everyone perfectly understood: our solution & the real problem. So,
discussions are biased by the one that speak louder.

I know it can be frustrating as we lead OpenERP like Linus Torvalds lead
Linux: on our core module we have the final decision on any merge. But
that has been the strength of OpenERP: having a clear direction.

We are all very smart: You are smart and We are smart too. So, if we
succeed concentrating a real issues/use cases (and not trying to push
our own solution without fully understanding other ones) we should agree
on the best scenario.

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

[Joël Grand-Guillaume @ camptocamp (jgrandguillaume-c2c)]

Re Fabien comment #38:

Well Fabien, I know you since 7 years now and I most of the time was beside you for your approach and decision.. But here, honestly, you can't say that to me... 1st april is over and it no more the time for joke ;) !

A quick look on the link provided by Alexandre here : http://msdn.microsoft.com/en-us/library/gg309704.aspx show you that the data model they use is not the one you try to defend here.

This time my friend you are wrong, I'm sorry. The best you can do IMO is to accept it. Errare humanum est.

Listen us all, we're all old partners and users, we all respect your vision and your product, we are not just complaining because we're not happy. We cannot make our business work with this change or only at high cost...

Regards,

Joël

[Stefan Rijnhart (Opener) (stefan-opener)]

On 04/09/2013 12:08 PM, Fabien (Open ERP) wrote:
> You will not have problems of several lines in your group_by reports

Not for invoices but will have problems for sale orders e.a.

> - We do agree that adding a partner_id field on the object for the
> legal entity (not on the view) linking to the main company is a
> good improvement. It's even in our proposition. (read Olivier's
> proposal)

This is ambiguous. AFAIK you are adding a field on the contact referring
to the main company. We need a field on business documents referring to
the main company as well. I suggest we call it 'partner_id'.

[Nhomar - Vauxoo (nhomar)]

Hello Fabien.

Reading better your comments, I think here we have Just one more issue.

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

> On 04/09/2013 01:19 AM, Raphaël Valyi - http://www.akretion.com wrote:
> > 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)...
>
> That's probably the biggest misunderstanding and the reason why we are
> not aligned with the best solution.
>
> If you read carefully the proposition of Olivier:
>
> - We do not plan to allow invoicing to contacts (in the meaning of
> the person who purchased, or a contact person)
> - We allow invoicing ONLY on "Valid Invoicing Entities"
>
> Be sure you understood the two lines above as it's the biggest
> misunderstanding in all our discussions.
>
> That's what Olivier calls the valid level of granularity for invoicing
> operations.
>
>
> With the default configuration:
>
> - The "Valid Invoicing Entity" is the company itself (Camptocamp),
> not the person (Joël, Camptocamp)
> - So, All invoices will be entitled to Camptocamp, not Joël of
> Camptocamp in the default configuration. Whether it comes from
> a sale order or a manual invoice, the behaviour must be the same.
> Invoices are only entitled to Camptocamp by default.
>
> The great improvement with the v7 approach is that we are also able to
> manage hierarchies of partners. (we had hierarchies in v6.1, but it was
> not used anywhere, so not useful at all)
>
> So, if you want to define hierarchies of companies:
>
> - Camptocamp Group [is company]
> - Camptocamp Switzerland [is company]
> - Joël
> - Camptocamp France [is company]
> - Marc
> - Cécile, Accounting Department
>
> With Olivier's proposition, by default, OpenERP allows invcoing to C2C
> Group, C2C Switzerland, C2C France. Not to the 3 others contacts. This
> is the expected behaviour.
>
>
> But, if the user wants (only if he explicitly configure OpenERP to allow
> it), he can also say that "Accounting Department" is a "Valid Invoicing
> Entity" by setting it's address type to 'Invoicing'. (which is not the
> default).
>

Can you explain better this configuration please, with some tests?, I cant
see them explicitally in any place.

>
> In this case, we think that the "Valid Invoicing Entity" is the right
> level of granularity for most reporting.
>
> Please note also that there is usually only one "Valid Invoicing Entity"
> per company. So all invoices to Camptocamp France will be entitled to
> "Camptocamp France, Accounting Departement".
>

Well, If you are in countries with Strong Fiscal Rules, this is not the
ususally, this is just the common ground Just in little companies, with
middle business models B2B the history is different.

>
> You will not have problems of several lines in your group_by reports,
> unless you manually decide to have two "Valid Invoicing Entities" for
> the same company AND you create a manual invoice for the other. (which
> is a...

[Nhomar - Vauxoo (nhomar)]

FYI Fabien.

I am EXACTLY in the same position as Joel....

We are with you, please accept the mistake, (everybody will love you more
;-))

No more Jokes.

2013/4/9 Joël Grand-Guillaume @ camptocamp <
<email address hidden>>

> Re Fabien comment #38:
>
> Well Fabien, I know you since 7 years now and I most of the time was
> beside you for your approach and decision.. But here, honestly, you
> can't say that to me... 1st april is over and it no more the time for
> joke ;) !
>
> A quick look on the link provided by Alexandre here :
> http://msdn.microsoft.com/en-us/library/gg309704.aspx show you that the
> data model they use is not the one you try to defend here.
>
> This time my friend you are wrong, I'm sorry. The best you can do IMO is
> to accept it. Errare humanum est.
>
> Listen us all, we're all old partners and users, we all respect your
> vision and your product, we are not just complaining because we're not
> happy. We cannot make our business work with this change or only at high
> cost...
>
> Regards,
>
>
> Joël
>
> --
> 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.
>
> == ...

[Joël Grand-Guillaume @ camptocamp (jgrandguillaume-c2c)]

+1 for Stefan. If we add a field, we need it on business document, and that's all we asked for since the beginning.

@Fabien: I write my comments while you posted yours, doesn't have seen your answer, sorry for that.

[Nhomar - Vauxoo (nhomar)]

@Fabien.

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

> On 04/09/2013 10:19 AM, Stefan Rijnhart (Therp) wrote:
> > @Fabien I yet have to hear approval for your approach from any
> > established OpenERP partner or other stakeholders. If the partners that
> > do speak up all disapprove, they can not all be wrong.
>
> Yes and no.
>
> No: This reminds me the GTK discussions; everyone wanted to maintain
> GTK, fork, stay on v6.1, ... At the end, focusing on one clean web
> client was one of the most important move OpenERP did in the pasts months.
>
> Yes: This means we have to bring a big attention on the issue. We have
> to understand everyone's argument, evaluate all proposed solutions and
> find the best ones. And that's what we are doing.
>
>
> We are just not convinced by proposed arguments and we think there have
> been a lot of misunderstandings/confusions/noise on the issue. Not
> everyone perfectly understood: our solution & the real problem. So,
> discussions are biased by the one that speak louder.
>
>
> I know it can be frustrating as we lead OpenERP like Linus Torvalds lead
> Linux: on our core module we have the final decision on any merge. But
> that has been the strength of OpenERP: having a clear direction.
>
>
> We are all very smart: You are smart and We are smart too. So, if we
> succeed concentrating a real issues/use cases (and not trying to push
> our own solution without fully understanding other ones) we should agree
> on the best scenario.
>

I am totally agreed with this PoV Fabien, and even I speak so loud today i
must to say you one thinking in my side.

I am trying to make Objective all my points, and all here are doing, but,
this time, I think again, you are comparing in a wrong way the problem.

Linux, is an operative System, is you change the structure your data stay
inmaculated, imagine Linus Say -without any consult-, "Hey from now we will
delete all first page of the writter docs, because this is not necesary
'usually' it has just the cover" and after say this he make the push
silently and all documents start to be lost....

Do you understand my Analogy?

My Friend, again we are with you, always, our Plan of Life is with OpenERP
or dying trying, but please, this kind of changes __must__ to be discussing
at least for 2 trunks.... and better analysed, IMHO, this result is about
the misunderstanding from your side of the importance of an ERP in a
Company, we can't delete a process just because it is not generic... in
this way you will finish being Excel , Dont you think?

>
>
> --
> Fabien Pinckaers
> CEO OpenERP
> Chaussée de Namur 40
> B-1367 Grand-Rosière
> Belgium
> Phone: [phone]
> Fax: [phone]
> 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 r...

[Goran Kliska (gkliska)]

Commenting comment #46
I have first hand experience with MS CRM/Navision
(was in charge implementing largest ones here)

Please don't copy that model!!!
One of my main motives for OpenERP was frustration with M$ and their data models.
Please listen to Nhomar, Ana, Raphael, Therp, Guewen, Joel and others, they know better than M$.

To minimize noise I will not list bad designs in MS, but (as Nhomar said) few good ones in MS CRM:
 - separate address entity (+ easy GUI for 2 defaults)
 - separate relationship entity

1. I think there is unanimous consensus about partner_id.
    IMO It is stronger than "No schema change in stable"

2. There is will, interest, knowledge to improve and test partner entity before major release
     If it will be a change, let's make really good one or revert to 6.1.
     Ideally it should be clear to junior programmer what is what:
         Party, Organization, Person, Contact, Employee, Cust/Supp, Address, Location,...?
         What is a Contact?
             A) Not a Company that is 1 level child_of Company (and Address in the same time)
             or
             B) Person related to Organization having 'contact' role and possibly other roles. (+ Customer/Supplier for domains)
     While designing think about existing and future verticals and localizations, for example:
             Unique VAT no.
             School, training, medical verticals
                   How to extend Person object to be Patient and Physician in the same time not knowing what is a Person?
                   How to model a Family? (It is a kind of relationship between Persons)
     Can we model Departments, Sale teams... as relationship between Persons with a Role of employee, optional hierarchy?

Regards,
Goran Kliska

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Hello Fabien, in #50 you said:

That's probably the biggest misunderstanding and the reason why we are
> not aligned with the best solution.
>
> If you read carefully the proposition of Olivier:
>
> - We do not plan to allow invoicing to contacts (in the meaning of
> the person who purchased, or a contact person)
> - We allow invoicing ONLY on "Valid Invoicing Entities"
>
> Be sure you understood the two lines above as it's the biggest
> misunderstanding in all our discussions.
>

Wait a minute, in the CRM example that made me discover the issue, you
spent around 10 answers explaining us my bug report was invalid and that it
was perfectly expected to invoice the contact created in the CRM as the
default flows does.
https://bugs.launchpad.net/openobject-addons/+bug/1155679

It's a bit intelectually dishonest you now accuse us of speaking loud and
not understanding your proposal while 2 weeks ago you were writing this
yourself:
https://bugs.launchpad.net/openobject-addons/+bug/1155679/comments/8
That is that is was perfectly expected to invoice a contact, that I was
wrong, and that you already adapted OpenERP to generate the correct
financial moves even when you invoice a contact...

So now, with the proposed change
https://code.launchpad.net/~openerp-dev/openobject-addons/7.0-fix-contact-company-handling/+merge/157576
in account/account_invoice_view.xml line 46 (search
"account_invoice_view"), you are now back pedaling half way and arbitrary
forbidding to select a contact in an invoice directly. That is you are just
making OpenERP inconsistent: depending on the flow you can invoice a
contact or not!

If a flow allows to invoice a contact in some way, believe us, the user
WILL do it and we WILL have the trouble.

Also, we may not invoice the contact anymore after that
strange inconsistent change, for large companies, we would still need a
contact to know where to send the invoice...

AND in any case, I we said, the problem is not at all with just the
invoices. It's with all OpenERP objects, not even just main business
documents. Indeed, if somewhere two OpenERP objects of a given business
flow belong to the same customer or supplier but have a different
partner_id just because in some it can be a contact and in the other one it
cannot, then this kills the possibility to properly relate these objects,
that is that kills usability and that makes OpenERP a bad system to analyse
your business data once you recorded business facts with it. So, we don't
need a halfway solution, we need the two keys in all objects (unless you
completely drop contact management but that would be a bad fatal regression
too).

So while you are claiming we don't understand (strange all the most
experiences OpenERP integrators don't understand), you are telling us in
comment #38:

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

[Sébastien BEAU - http://www.akretion.com (sebastien.beau)]

Hi Fabien

>So, if you want to define hierarchies of companies:
>
> - Camptocamp Group [is company]
> - Camptocamp Switzerland [is company]
> - Joël
> - Camptocamp France [is company]
> - Marc
> - Cécile, Accounting Department

So finaly all of this change for simply invoicing a "special" partner with your solution?
Keeping the solution with 2 fields I think wil be simplier and easier for user

Indeed in the partner_id will be able to put "Camptocamp Group", "Camptocamp France", "Camptocamp Switzerland"
and in the contact_id we will be able to put "Joel", "Marc", "Cécile".
If you only want to allow the user to set "Cécile" than we can simply add a type for the contact of a company (sale department, accounting departement....) and add a filter on the contact_id of an invoice.

With this solution you will avoid to change a lot of code and to have a datamodel more complicated.
Also you will not break the "group_by" because the user will randowly invoice "Camptocamp France" or "Cécile, Accounting Département"

For simple case you can only keep one field and you have the same behaviour without changing all of the code logic

Please never forgert "KISS" "Keep It Simple and Stupid"

>No: This reminds me the GTK discussions; everyone wanted to maintain
>GTK, fork, stay on v6.1, ... At the end, focusing on one clean web
>client was one of the most important move OpenERP did in the pasts months.

This is really different with the GTK discution, because in this case the majority of partner was agree with dropping the GTK client, and some partner was asking for maintaining it. But this time I don't see any OpenERP agree with you, and this is REALLY DIFFERENT.

Please take your time before merging a solution. We are in the same boat

Thanks you

[Maxime Chambreuil (http://www.savoirfairelinux.com) (max3903)]

After testing the 2 solutions provided by rvalyi and odony, we vote for rvalyi's solution for backward compatibility.

@ Fabien

We think that the OpenERP project has reached a critical mass of users and integrators in its lifecycle where those big changes should be discussed with Gold Partners and/or Community Reviewers during OpenERP Community Days. Your baby has grown and you need to give him some space to continue growing.

You were able to do that couple years ago, but there is now 3000+ modules and lots of people depending on them. Those people built and used those 3000+ modules based on the assumption that documents requiring 2 fields used partner_id and contact_id. You cannot change this assumption on your own. It generates frustration on both sides.

I think you have a great opportunity today to decide how and with who you want to build the future of OpenERP. I think the community is ready and well-structured to help you.

[Ana Juaristi Olalde (ajuaristio)]

Just a little note about this concern.
Today I have received a really good detailed requirement analysis document from a lead asking for a quotation.

One of the requirements I'm reading just on document beginning:

A child table of PEOPLE - ADRESSDETAILS must be created in a separate table containing exactly this fields:
Address Line 1* Text
Address Line 2 Text
Address Line 3 Text
Town / City* Text
State / Province / County Text
Zip Code / Post Code Text
Country* Dropdown
Mail Box Text
Street Number Text
Type* Dropdown
People meaning could be any CONTACT related to a company, an EMPLOYEE, an APLICANT, a CANDIDATE.
-----
So... They are considering different entity partner-people and they need having address in a separate entity. On the other side, I see really difficult offering solution with OpenERP 7.0 aproach to this new VERY BIG lead. Really affordable with OpenERP 6.X. What should I do? Wait for a solution and probably lose the customer? Make quotation with 6.1? For me answer is clear on this point.
It's not my intention adding more wood to make fire bigger, just to try to show real customer/leads needs. I thought it was interesting telling you this case that happened to me today.
Thank you very much:
Ana

[Fabien (Open ERP) (fp-tinyerp)]

> One of the requirements I'm reading just on document beginning:
>
> A child table of PEOPLE - ADRESSDETAILS must be created in a separate table containing exactly this fields:
> Address Line 1* Text
> Address Line 2 Text
> Address Line 3 Text
> Town / City* Text
> State / Province / County Text
> Zip Code / Post Code Text
> Country* Dropdown
> Mail Box Text
> Street Number Text
> Type* Dropdown
> People meaning could be any CONTACT related to a company, an EMPLOYEE, an APLICANT, a CANDIDATE.

I don't understand? What's the feature you can not handle in v7 according to this need?

Does he want each people having different address? If yes, install base_contact. If no, openerp handles it correctly.

In terms of relationship between entities; there are no scenario you can do in v6.1 that you can not do in v7.

> What should I do? Wait for a solution and probably lose the customer? Make quotation with 6.1? For me answer is clear on this point.

Up to you, but be sure you understood and balance perfectly the pros and cons before taking such a decision. In my opinion this could be a big mistake.

> It's not my intention adding more wood to make fire bigger, just to try to show real customer/leads needs. I thought it was interesting telling you this case that happened to me today.
> Thank you very much:
> Ana
>
> --
> 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
>
> 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
...

[Nicolas JEUDY (njeudy)]

+1 for partner_id + contact_id

For me it is very important to have one clear partner field that is the "legal commercial part" (it can be company or not)

For the contact_id it is just a person at a time that represent this company, but this person/contact change and is just for communication (like partner_ids on meetings and so).

All my cutomers understand that you have a customer part and one or more contacts for this customer. If you only want one field, remove contact on business document and use openchatter to communicate.

[Guewen Baconnier @ Camptocamp (gbaconnier-c2c)]

The fact is that you gave the example of the invoice. The invoice has been modified in the merge proposal to only accept invoice-able partners.
So, a priori, you don't mix partners and contacts (or addresses).

An example of issue by mixing partners and contacts / addresses.

I will not use a company for the example, but an individual customer.

The customer is Joël Grand-Guillaume (id: 5), the address on this record is his home address.
He has a second address registered, at work, because he want to be delivery there (id: 6).

He phones because he want to address a complaint.
A claim is created on Joël Grand-Guillaume.

He phones again for another claim.
The user selects the wrong entry, he choose the work address instead of the main one.

We have 2 claims, one time the partner_id is a partner and the second time it is an address.

If you open the Joël Grand-Guillaume's main view, and display the 'History' tab, you should see the full list of claims of Joël.
But you won't see the second one, the second claim is displayed on his work address. (Same history if we group by partner)

Technically correct, but not what a user would like.

By cons, if we name the field displayed to the user 'contact_id' (we'll have id 6), and we automatically fill the 'partner_id' with the id 5, we can group by partner_id and link the partner to all his claims in the history tab using partner_id.

[Joël Grand-Guillaume @ camptocamp (jgrandguillaume-c2c)]

+1 for Maxime's comment #61 => I think the community is now ready and sufficiently organized to provide feed-back for such changes.

By the way, I also tested Raphaël's branch and I also vote for it in the way it solve this problem :

 * keeping retro-compatibility
 * providing 2 stored fields on business document in a generic way
 * even if not provided yet, it is easily extendable to add a partner_id on the form (or let it hide for an "easy" use)

The best solution IMO would be to take the Raphaël Valyi's module, removing the insane method name and keeping O.Dony's way of computing the commercial_entity, improving the view by marking Read Only when choosing belong to company and so.

Olivier did a great job and it's sad to lose everything here. But we DO NEED TWO fields on business document.

Thanks,

[Guewen Baconnier @ Camptocamp (gbaconnier-c2c)]

Note that by restricting the domain in the invoice with only invoice-able partners, you, by the facts, admit that the notion of 1st class partners always interchangeable does not exist.

A company, a contact or an address are not always interchangeable, even if you would like to believe the opposite, and that's the key of the problem raised by the community.

[Mathieu Vatel - Julius Network Solutions (mathieu-julius)]

+1 for partner_id + contact_id fields.

We definitely need two fields to manage business data!

[Ana Juaristi Olalde (ajuaristio)]

Hi Fabien:
About your comment #63 now I understand almost NOTHING.
Are you telling that base_contact at last on 7.0 will be not depreciated and we will have the option of having same partner-address-contact structure we had on 6.1, even if contacts are stored on partners table?
Will we have a separate address table being able to assign on different documents and reusing them on different objects?
If this is like that, I don't know what are we discussing for months.

Please, I would like to clarify this point since I'm just shocked with the answer.

Thank you very much:
Ana

[Nhomar - Vauxoo (nhomar)]

Hello all.

+1 for 2 fields, and correctly managed.

It means, if for useability reasons OpenERP think they must remove one (as
they did) They should have the option to put hiden and fill it silently.

BUT, Now i think it is a mixed approach Raph and Odony.

Point 1.-

IMHO it is a good idea have a centrilized method on partners to return the
commercial entity, in this way the res.partner object can become in
something like an "COmmerical Contact management API" that return the id
decided and we can manage in our localizations - business elements, it
sound cool that in a centrilized method you can decide how manage your own
partner_id.id record to save, but we need a clean method as Ododny did to
do that, I think just it must consider Multi-Company and at once Ir.Rules
and Multi-localization what i think is not considered yet.

Point 2.-
The main issue here is that in business object decision take in the moment
the record was saved must to be saved in data base.

This is solved with rvalyi module.

Point 3.-
And, I think we need a basic constraint that if some business document was
done the structure of the partner must not be changed (we didn't have in
V6.1 but it is a should be)

To solve some Human errors so easy to make.

If we decide put the extra field, it must be considered IMHO as part of the
OPW, because I think it is representing a lost of functionality.

Point 4.- About Documentation.

I think OpenERP SA this specific time should fill a book or a blo post at
least with the explanation of the comparative between the casuistic between
6.1 and 7.0 to avoid misunderstood and not waste time in blank points.

Ok, I hope my 2 cents help better this time.

2013/4/10 Mathieu Vatel - Julius Network Solutions <
<email address hidden>>

> +1 for partner_id + contact_id fields.
>
> We definitely need two fields to manage business data!
>
> --
> 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
> usua...

[Nhomar - Vauxoo (nhomar)]

@Fabien

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

> > One of the requirements I'm reading just on document beginning:
> >
> > A child table of PEOPLE - ADRESSDETAILS must be created in a separate
> table containing exactly this fields:
> > Address Line 1* Text
> > Address Line 2 Text
> > Address Line 3 Text
> > Town / City* Text
> > State / Province / County Text
> > Zip Code / Post Code Text
> > Country* Dropdown
> > Mail Box Text
> > Street Number Text
> > Type* Dropdown
> > People meaning could be any CONTACT related to a company, an EMPLOYEE,
> an APLICANT, a CANDIDATE.
>
> I don't understand? What's the feature you can not handle in v7
> according to this need?
>
> Does he want each people having different address? If yes, install
> base_contact. If no, openerp handles it correctly.
>

I am like Condorito, where is <email address hidden>?

>
> In terms of relationship between entities; there are no scenario you can
> do in v6.1 that you can not do in v7.
>
>
> > What should I do? Wait for a solution and probably lose the customer?
> Make quotation with 6.1? For me answer is clear on this point.
>
> Up to you, but be sure you understood and balance perfectly the pros and
> cons before taking such a decision. In my opinion this could be a big
> mistake.
>
>
> > It's not my intention adding more wood to make fire bigger, just to try
> to show real customer/leads needs. I thought it was interesting telling you
> this case that happened to me today.
> > Thank you very much:
> > Ana
> >
> > --
> > 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
> >
> > 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.
> >...

[Fabien (Open ERP) (fp-tinyerp)]

On 04/09/2013 12:23 PM, Stefan Rijnhart (Therp) wrote:
> On 04/09/2013 12:08 PM, Fabien (Open ERP) wrote:
>> You will not have problems of several lines in your group_by reports
>
> Not for invoices but will have problems for sale orders e.a.
>
>> - We do agree that adding a partner_id field on the object for the
>> legal entity (not on the view) linking to the main company is a
>> good improvement. It's even in our proposition. (read Olivier's
>> proposal)
>
> This is ambiguous. AFAIK you are adding a field on the contact referring
> to the main company. We need a field on business documents referring to
> the main company as well. I suggest we call it 'partner_id'.
>

Yes, that's what I meant: adding a field "commercial entity" linking to
the main company on the invoice.

One way to integrate it in v7.0 without breaking our "no change in
schema in stable release" is to add this field in a new module in v7. We
will do it and integrate in v7.

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

[Fabien (Open ERP) (fp-tinyerp)]

> Are you telling that base_contact at last on 7.0 will be not depreciated
> and we will have the option of having same partner-address-contact
> structure we had on 6.1, even if contacts are stored on partners
> table?

Yes, we re-developped a better base_contact allowing the exact same
features than the 6.1 one, but the structure is a bit different.

We had to support it has we noticed we had OpenERP Enterprise customers
using it. It has been announced 2 months ago.

It's under code review now. You can test this branch on runbot:
  7.0-base-contact-xal

> Will we have a separate address table being able to assign on different
> documents and reusing them on different objects?
> If this is like that, I don't know what are we discussing for months.

Technically, it's not implemented like that, but it does what you need:
  - one person working for several companies or having several addresses

The useability is different than in v6.1 but all people that tested it
think it's better.

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

[Stefan Rijnhart (Opener) (stefan-opener)]

On 04/10/2013 10:35 AM, Fabien (Open ERP) wrote:
> Yes, that's what I meant: adding a field "commercial entity" linking
> to the main company on the invoice. One way to integrate it in v7.0
> without breaking our "no change in schema in stable release" is to add
> this field in a new module in v7. We will do it and integrate in v7.

Please don't. That is just *inconsistently* swapping out the meaning of
the 'partner_id' to contact. Add a field 'contact_id' so that
'partner_id' can keep referring to the company partner.

If your dogmatic release policy forbids it, forcing you into such a
dangerous move, then maybe you can implement the correct decision after
all and just call it OpenERP 7.1 and release next week.

[Guewen Baconnier @ Camptocamp (gbaconnier-c2c)]

Fabien,

Your thoughts on the use case in the comment #65?
Do you think normal to split the history within the hierarchy? Do you call that an usability improvement?
Or do you admit that we need to have a reliable partner_id which is clear on what is type is: a partner, not an address or a contact.

Thanks

[Fabien (Open ERP) (fp-tinyerp)]

On 04/10/2013 01:02 PM, Guewen Baconnier @ Camptocamp wrote:
> Do you think normal to split the history within the hierarchy?
> Do you call that an usability improvement?

Yes. It's ok. Both approaches are ok, but when we balances pros and
cons, the one we chose seems the best.

On a hierarchy:

  Camptocamp Group
    Camptocamp France
      Luc Maurer

If you click "Claims" on Luc Maurer (or search Luc Maurer in claims) you
get all claims from Luc Maurer, but not the claims from other employees
of C2C.

If you click "Claims" on Camptocamp France, you get all claims of the
company and all it's employees.

That looks like a normal behaviour for me.

It's the same for B2C, one contact with 2 or three addresses:

  Joël
    Joël, Switzerland
    Joël, France

If I search delivery orders for "Joël, France", I get only those sent to
Joël France, which looks like what the user expect. If I search for
"Joël", I get everything linked to Joël (France+Switzerland), which is
also what the user expect, especially because the search dialog is quite
clear, it will propose 3 values:
  Joël
  Joël (Switzerland)
  Joël (France)

It looks normal to me that if I select "Joël (Switzerland)", I fon't get
the delivery orders to "Joël (France)".

PS: Note that we have to check that child_of is used everywhere, rather
than '='. I am note sure it's clean everywhere.

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

[Guewen Baconnier @ Camptocamp (gbaconnier-c2c)]

On 04/10/2013 02:17 PM, Fabien (Open ERP) wrote:
> On 04/10/2013 01:02 PM, Guewen Baconnier @ Camptocamp wrote:
>> Do you think normal to split the history within the hierarchy?
>> Do you call that an usability improvement?
>
> Yes. It's ok. Both approaches are ok, but when we balances pros and
> cons, the one we chose seems the best.
>
> On a hierarchy:
>
> Camptocamp Group
> Camptocamp France
> Luc Maurer
>
> If you click "Claims" on Luc Maurer (or search Luc Maurer in claims) you
> get all claims from Luc Maurer, but not the claims from other employees
> of C2C.
>
> If you click "Claims" on Camptocamp France, you get all claims of the
> company and all it's employees.
>
> That looks like a normal behaviour for me.
>

That sounds ok to me... but
1. The link does not use a child_of actually, but if that's your
intention, ok
2. When you click on the *link* Claims because it uses a domain with a
child_of. But what for the *one2many fields*, are you going to replace
them all by a fields.function using a child_of instead of a = ?
Example: the one2many displaying the claims in the history tab of
Camptocamp Group won't display the claims from other employees while the
link will. If you need to create a link with a 'child_of' because you
can't rely on the one2many fields, that's a pity.

>
> It's the same for B2C, one contact with 2 or three addresses:
>
> Joël
> Joël, Switzerland
> Joël, France
>
> If I search delivery orders for "Joël, France", I get only those sent to
> Joël France, which looks like what the user expect. If I search for
> "Joël", I get everything linked to Joël (France+Switzerland), which is
> also what the user expect, especially because the search dialog is quite
> clear, it will propose 3 values:
> Joël
> Joël (Switzerland)
> Joël (France)
>
> It looks normal to me that if I select "Joël (Switzerland)", I fon't get
> the delivery orders to "Joël (France)".
>

Ok, in theory that's sound ok (didn't check if it works really like
that). But that right for the delivery orders, not the claims for
instance. And again, your case gently ignore the truth: yes, the search
can be customized to search on child_of, as per the the links. But the
one2many linked with the partner_id of the delivery won't be able to
display the correct information.

>
> PS: Note that we have to check that child_of is used everywhere, rather
> than '='. I am note sure it's clean everywhere.
>
>

--
Guewen Baconnier
Business Solutions Software Developer

Camptocamp SA
PSE A, CH-1015 Lausanne
Phone: [phone]
Office: [phone]
http://www.camptocamp.com/

[Fabien (Open ERP) (fp-tinyerp)]

On 04/10/2013 02:49 PM, Guewen Baconnier @ Camptocamp wrote:
> 2. When you click on the *link* Claims because it uses a domain with a
> child_of. But what for the *one2many fields*, are you going to replace
> them all by a fields.function using a child_of instead of a = ?

Actually we plan to remove one2many fields from form views, it was a bad
usability approach. (we already have a branch that removed all remaining
in trunk) We removed a lot of them in v7 and replaced them by buttons in
the top right corner.

It's much better as it's faster, opens a new view in the breadcrum, with
a search and an easy (full screen) create/edit form view.

> Example: the one2many displaying the claims in the history tab of
> Camptocamp Group won't display the claims from other employees while the
> link will. If you need to create a link with a 'child_of' because you
> can't rely on the one2many fields, that's a pity.

We don't think "one2many inside forms" is the best way to go. But if you
absolutly want to do that, you will have to do a hack (that's part of
the cons when I say you have to balance pros and cons)

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

[Stefan Rijnhart (Opener) (stefan-opener)]

> Actually we plan to remove one2many fields from form views

Fabien, could you please share the location of that branch, so that I can see for myself that 'removing one2many fields from form views' is not as bad as it sounds?

Thanks

[Guewen Baconnier @ Camptocamp (gbaconnier-c2c)]

On 04/10/2013 03:06 PM, Fabien (Open ERP) wrote:
> On 04/10/2013 02:49 PM, Guewen Baconnier @ Camptocamp wrote:
>> 2. When you click on the *link* Claims because it uses a domain with a
>> child_of. But what for the *one2many fields*, are you going to replace
>> them all by a fields.function using a child_of instead of a = ?
>
> Actually we plan to remove one2many fields from form views, it was a bad
> usability approach. (we already have a branch that removed all remaining
> in trunk) We removed a lot of them in v7 and replaced them by buttons in
> the top right corner.
>
> It's much better as it's faster, opens a new view in the breadcrum, with
> a search and an easy (full screen) create/edit form view.
>
>> Example: the one2many displaying the claims in the history tab of
>> Camptocamp Group won't display the claims from other employees while the
>> link will. If you need to create a link with a 'child_of' because you
>> can't rely on the one2many fields, that's a pity.
>
> We don't think "one2many inside forms" is the best way to go. But if you
> absolutly want to do that, you will have to do a hack (that's part of
> the cons when I say you have to balance pros and cons)
>

That's an end user point of view. I won't argue because that's not the
most important point for me, even if it sounds a bit like 'we remove
them because they reveal the flaws of our model'.

So, finally you admit that you broke the o2m relations linked to
res.partner, and you have to admit that you broke all the community
modules which were relying on the one2many, expecting that a o2m was
linked to the correct partner_id. And that without any note or warning.

--
Guewen Baconnier
Business Solutions Software Developer

Camptocamp SA
PSE A, CH-1015 Lausanne
Phone: [phone]
Office: [phone]
http://www.camptocamp.com/

[Guewen Baconnier @ Camptocamp (gbaconnier-c2c)]

On 04/10/2013 04:26 PM, Guewen Baconnier wrote:

> That's an end user point of view. I won't argue because that's not the
> most important point for me, even if it sounds a bit like 'we remove
> them because they reveal the flaws of our model'.
>
> So, finally you admit that you broke the o2m relations linked to
> res.partner, and you have to admit that you broke all the community
> modules which were relying on the one2many, expecting that a o2m was
> linked to the correct partner_id. And that without any note or warning.
>

I meant that the problem on views can be "fixed" by replacing the o2m in
views by links / buttons.

But that's "only" a view problem.

The same can occurs in the code, in the logic of the code, and I don't
think any of:
  - the official addons
  - the community addons
have been adapted to use the 'child_of' instead of the '='.

--
Guewen Baconnier
Business Solutions Software Developer

Camptocamp SA
PSE A, CH-1015 Lausanne
Phone: [phone]
Office: [phone]
http://www.camptocamp.com/

[Maxime Chambreuil (http://www.savoirfairelinux.com) (max3903)]

One drawback of the child_of approach is with third-party integration. If you access OpenERP database to synchronize data with third-party software or for reporting purposes, you will need to reimplement the child_of logic.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

And in any case, such semantic and conceptual changes should have been debated explicitly at least 1 year before a version, certainly not 100 days after the "LTS" release. Now trying to hide the conceptual errors with a model that is conceptually bad anyway.

So if OpenERP SA wants to debate about doing that in version 9 or 10, no problem, start debating it, no problem. At least people will freely be able to decide in advance if they stay on the same boat or not. But as for version 7, we have to fix it in the more consistent and less risky way.

We partners already sold OPW contracts to our customers telling them "you know, with that it will be easier to migrate to that great version 7.0". Had we known these plans to kill the data model (and now the view layer?), we would probably not have sold that dream. But now we are owing a solution to our customers. I mean a real solution, a version that they expected to be better than the past ones, not something that will just hide them the problems on the surface.

And now there is a strong consensus about how to do that, only OpenERP SA is refusing to see what is now obvious to everybody. That is very sad.

[Eckhard Schwarzat (e-schwarzat)]

+1

Couldn't have better expressed myself, thanks Raphaël.

Eckhard Schwarzat
Valuedecision Ltd.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

One more precision: 'child_of' is not even going to do enough unless you still add a new field.

Imagine again you are receiving Return Material Authorization picking. In that picking, the user has set partner_id to the contact of a company. now you want to relate that picking with an existing CRM claim of the same company. What you should filter in the domain is: claims from the parent company (kind of child_of thing), BUT, you should also show siblings contacts of the same contact of the picking. That is unless you add new stored field like commercial_entity_id, child_of is not going to do the trick. And then, if you talk again about adding that damned second key, then the right choice is to keep partner_id as the commercial/legal entity like it has always been and add a new contact_id field like in my module here https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/27

CQFD

[Felix Schubert (input-fescon)]

+1 for partner_id + contact_id

Thx to Raphaël and all the other long time experienced partners for their comments and their investigations.

Felix Schubert

[Fabien (Open ERP) (fp-tinyerp)]

On 10/04/13 15:53, Stefan Rijnhart (Therp) wrote:
>> Actually we plan to remove one2many fields from form views
> Fabien, could you please share the location of that branch, so that I
> can see for myself that 'removing one2many fields from form views' is
> not as bad as it sounds?

Sorry, I was not clear.

We do not want to remove one2many. We want to remove one2many fields
that were used for history and replace them by related action button.
Most of
them have already been replaced by buttons in v7.

As an example, on the partner form: Tasks, Meetings, Opportunities, Sales
are not integrated as one2many of the parnter but as a button on the partner
to open these views.

Nearly all of these one2many have already been replaced by buttons in v7.
Only 4 are remaining in the partner form: Campains, Tasks, Events, Claims.
These 4 should be replaced by buttons in v7, like we already did for other
actions.

In the future, I also think that we should add a number, like "4 Sales
Order",
in the button, like we did in the kanban view of partners.

Fabien

[Olivier Dony (Odoo) (odo-openerp)]

On 04/10/2013 03:06 PM, Fabien (Open ERP) wrote:
> Actually we plan to remove one2many fields from form views, it was a bad
> usability approach. (we already have a branch that removed all remaining
> in trunk) We removed a lot of them in v7 and replaced them by buttons in
> the top right corner.

As you probably guessed, Fabien was talking about one2many fields on the
*Partner form* view, and similar cases where the one2many field does not
represent a parent-child relationship. In many of these cases this [reverse]
o2m relationship was only added to the model as a way to embed a list of
"related items" in the form view. The idea is that those o2m relationships do
not need to be materialized and are best accessed as "related links",
previously located in the sidebar and now also as buttons in the form view.

[Stefan Rijnhart (Opener) (stefan-opener)]

Thanks for clearing that up. I take it that when Fabien said "if you absolutly want to [display a one2many widget], you will have to do a hack" he only meant "override the view and simply add the field to the form".

[Fabien (Open ERP) (fp-tinyerp)]

On 10/04/13 16:32, Guewen Baconnier @ Camptocamp wrote:
> On 04/10/2013 04:26 PM, Guewen Baconnier wrote:
>
>> That's an end user point of view. I won't argue because that's not the
>> most important point for me, even if it sounds a bit like 'we remove
>> them because they reveal the flaws of our model'.
>>
>> So, finally you admit that you broke the o2m relations linked to
>> res.partner, and you have to admit that you broke all the community
>> modules which were relying on the one2many, expecting that a o2m was
>> linked to the correct partner_id. And that without any note or warning.
>>
> I meant that the problem on views can be "fixed" by replacing the o2m in
> views by links / buttons.
>
> But that's "only" a view problem.

No, it's not a problem at all. It's the correct behaviour.

On this structure:
   Camptocamp
     - Camptocamp, France
     - Camptocamp, Switzerland

If I do a delivery order to "Camptocamp, France", it's normal that there are
no delivery order for "Camptocamp, Switzerland". The opposite would be a
mistake. And it's the same for claims, invoices, ... This is true for
the view
AND on the object. Having something else would be completly wrong.

If I understand, in the field claim_ids on the partner "Camptocamp", you
expect to see claims from "Camptocamp, France"? I don't think it has sense.
(at least according to the semantic we used to define partners which are
different entities)

The child_of we propose is not a way to 'simulate' that claims or
invocies to
"Camptocamp, Switzerland" also belong to "Camptocamp, France". That's
wrong, these are different.

It's just a tool to help searching recursively in the group (just a UI
feature) but
it's clear that each document belong to a different partner.

>
> The same can occurs in the code, in the logic of the code, and I don't
> think any of:
> - the official addons
> - the community addons
> have been adapted to use the 'child_of' instead of the '='.
>

[Stefan Rijnhart (Opener) (stefan-opener)]

On 04/10/2013 08:07 PM, Olivier Dony (OpenERP) wrote:
> As you probably guessed, Fabien was talking about one2many fields on
> the *Partner form* view

BTW, No I did not guess that, like I also did not guess that you would
remove the direct link to the company partner from the business
documents, then propose to add a *different* field with exactly that
function in a patchwork module while copying various data from the
company to its contacts.

[Fabien (Open ERP) (fp-tinyerp)]

On 10/04/13 17:06, Maxime Chambreuil (http://www.savoirfairelinux.com)
wrote:
> One drawback of the child_of approach is with third-party integration.
> If you access OpenERP database to synchronize data with third-party
> software or for reporting purposes, you will need to reimplement the
> child_of logic.
>
I don't understand your point ?

On:
     Camptocamp Holding
         Camptocamp CH
         Camptocamp FR
             Joel

If I do a claim for C2C CH, this claim does NOT belong to C2C holding. It's
normal that, on claim_ids for C2C Holding, I do not have the claim to
C2C CH.
What I said is that we have a UI feature in the web client allowing to get
claims of Camptocamp Holding and all it's subsidiaries.

IMHO, the behaviour is the same for Joël and Camptocamp.

Child_of is just a UI tool for searching inside a whole company or group.
Even if you want to develop a UI tool that has the same feature than the
web client, you do not need to implement child_of, you just pass a domain
with child_of in your RPC call.

Fabien

[Fabien (Open ERP) (fp-tinyerp)]

> Now trying to hide the conceptual errors
> with a model that is conceptually bad anyway.

This is where we disagree. We think the data model in v7 is good. (even
better than in v6.1).

On the invoice, we have a field partner_id which contains "Joël,
Camptocamp".
Your claim is that the data model is not good because it can not work
without
another field "Camptocamp". (let's call it partner_commercial_id)

This field must be:
   - related: it's implementation is one line:
fields.related('partner_id','commercial_id')
   - readonly: no other value than "Camptocamp" is possible

It's clear that adding a readonly function field:
   - DOES NOT change anything to the data model (you just add a redundancy)
   - DOES NOT change anything to what you can do in the code, instead of
doing
     invoice.partner_id.commercial_id, you would do:
invoice.partner_commercial_id

Your extra field is just a technical artifact to allow group_by on
"commercial
entities" in invoices rather than "invoiced entities". Nothing more.

We agree it's a good feature (we proposed it for v8 and, now we agree to
do a
module for v7) but: it's not a legal requirement, nor does it change
anything to
the data model (as you just add a function field)

To be clear, we did one mistake in v7; the contacts did not inherited
from accounting
fields from their companies (like pricelists, account receivable) We
should have
done what we did for the address for these fields too. We missed that
point. It's a
20 lines patch. The rest is just misunderstandings and fears.

> And in any case, such semantic and conceptual changes should have been
> debated explicitly at least 1 year before a version, certainly not 100
> days after the "LTS" release.

Yes, I do agree. We did not received enough feedback from the community
on the version 7, during the RC phase. We got much more feedback for v6.1.

These may be the reasons:
   - We did less Release Candidate for v7 (1) than 6.1. (3)
   - partners were expecting the v6.1 more than the v7 because there were
     2 years between v6.1 and v7, compared to 10 months between v6.1 and
     v7.
   - most partners were still in their v6.1 implementations (as this
version had
     only 10 months old) and none really had the time to test v7. On
v6.1, some
     even started to deploy on trunk

We will try to improve this for the next versions.

Fabien

[Maxime Chambreuil (http://www.savoirfairelinux.com) (max3903)]

@ Fabien

The problem is not in the UI, it is in the data model.

If you connect a third-party application to report on or export the number of records by company, if the record is for Joël, you will get 0 record for C2C FR. Expected result : 1 record.

So the third-party software would need to reimplement the child_of logic to find the company.

[Maxime Chambreuil (http://www.savoirfairelinux.com) (max3903)]

@ Fabien

On the performance perspective, I would be interested to know how you solution behave.

I foresee that your solution will save time on the write but increase on reporting.

Raphaël solution will take more time on the write (but won't be significant, it is just one field to compute), but will be faster when reporting (no need to look for the 1st commercial entity id).

Other scenario for you: how do you handle the case where Joël is now working for C2C CH ? Will its claim follow to C2C CH or will it stay with C2C FR ? From a user standpoint, I expect the claim to stay with C2C FR.

[Ana Juaristi Olalde (ajuaristio)]

My god... I'm getting desperate by now with all this history.
Why do you need including a new conceptual field partner_commercial_id
where partner_id used with that meaning is present on datamodel and
documents from begining??????? I don't understand the point.
Why don't you change aproach and mantain partner_id, even
partner_id.parent_id as it has been always and just add an additional field
contact_id not impacting on legal documents?

Seriously, I understand nothing.

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

> > Now trying to hide the conceptual errors
> > with a model that is conceptually bad anyway.
>
> This is where we disagree. We think the data model in v7 is good. (even
> better than in v6.1).
>
>
> On the invoice, we have a field partner_id which contains "Joël,
> Camptocamp".
> Your claim is that the data model is not good because it can not work
> without
> another field "Camptocamp". (let's call it partner_commercial_id)
>
> This field must be:
> - related: it's implementation is one line:
> fields.related('partner_id','commercial_id')
> - readonly: no other value than "Camptocamp" is possible
>
> It's clear that adding a readonly function field:
> - DOES NOT change anything to the data model (you just add a redundancy)
> - DOES NOT change anything to what you can do in the code, instead of
> doing
> invoice.partner_id.commercial_id, you would do:
> invoice.partner_commercial_id
>
>
> Your extra field is just a technical artifact to allow group_by on
> "commercial
> entities" in invoices rather than "invoiced entities". Nothing more.
>
> We agree it's a good feature (we proposed it for v8 and, now we agree to
> do a
> module for v7) but: it's not a legal requirement, nor does it change
> anything to
> the data model (as you just add a function field)
>
>
> To be clear, we did one mistake in v7; the contacts did not inherited
> from accounting
> fields from their companies (like pricelists, account receivable) We
> should have
> done what we did for the address for these fields too. We missed that
> point. It's a
> 20 lines patch. The rest is just misunderstandings and fears.
>
> > And in any case, such semantic and conceptual changes should have been
> > debated explicitly at least 1 year before a version, certainly not 100
> > days after the "LTS" release.
>
> Yes, I do agree. We did not received enough feedback from the community
> on the version 7, during the RC phase. We got much more feedback for v6.1.
>
> These may be the reasons:
> - We did less Release Candidate for v7 (1) than 6.1. (3)
> - partners were expecting the v6.1 more than the v7 because there were
> 2 years between v6.1 and v7, compared to 10 months between v6.1 and
> v7.
> - most partners were still in their v6.1 implementations (as this
> version had
> only 10 months old) and none really had the time to test v7. On
> v6.1, some
> even started to deploy on trunk
>
> We will try to improve this for the next versions.
>
>
> Fabien
>
> --
> You received this bug notification because you are subscribed to OpenERP
> Addons.
> https://bugs.launchpad.net/bugs/1160365
>
> Title:
> [7.0] incorrect handling of cont...

[Fabien (Open ERP) (fp-tinyerp)]

On 10/04/13 21:21, Maxime Chambreuil (http://www.savoirfairelinux.com)
wrote:
> @ Fabien
>
> The problem is not in the UI, it is in the data model.
>
> If you connect a third-party application to report on or export the
> number of records by company, if the record is for Joël, you will get 0
> record for C2C FR. Expected result : 1 record.

No, I think the record belongs to Joël, not C2C FR and certainly not to
both. In other words: an invoice to "Joël, C2C" is not the same than an
invoice to "C2C". (e.g. you send the invoice to <email address hidden>, not
<email address hidden>)

If you make the record belong to both, you will have others problems
like count(one2many) that will return twice the real number of records

Fabien

[Maxime Chambreuil (http://www.savoirfairelinux.com) (max3903)]

So you will run after Joël @ C2C CH to get paid for the invoice he received while he was working for C2C FR ?

Real life situation, Joël ask me to contact Alexandre @ C2C FR to get paid.

[Ana Juaristi Olalde (ajuaristio)]

@Fabien:
So... No, I think the record belongs to Joël, not C2C FR and certainly not to
both. In other words: an invoice to "Joël, C2C" is not the same than an
invoice to "C2C". (e.g. you send the invoice to <email address hidden>, not
<email address hidden>)
--> THIS IS JUST THE PROBLEM. An Invoice, belongs ALWAYS to C2C FR because your fiscal legal entity is C2C FR. Additionally you will send the invoice to Joêl or you could send to several other accountant contacts if you need, or even you could sent to general "info@" because it's the main email for company and additionally to contacts that you want to send. You are giving priority to communications instead of giving priority to legal requirement. Communications can be built as final customer decides. Even if you assume there is only one financial contact this assumtion can be wrong from final customer side but he can NEVER deny that invoice has to be behind the name of legal fiscal entity as is written by low in most countries I know.

If you make the record belong to both, you will have others problems
like count(one2many) that will return twice the real number of records
--> This is not exactly like that because if you have got 2 fields on documents you will always count sum(partner_id). You will always have correct number if you set correctly the domain depending on where you are launching the query. I don't see problem on that.

Please think about this aproach. Most important think here is that an ERP should not give priority to secondary functionality but always to principal one. On this case accounting is the principal because is set by law. Other functionalities are customizable and not so critical so they can be even avoided.
Thank you very much.
Ana

Fabien

[Ana Juaristi Olalde (ajuaristio)]

@maxime: THAT's EXACTLY THE POINT!!!
Joel could be fired, another contact could be hired. Joel could go in holidays, Joel could change department but C2C FR will be always C2C FR during it's registered as a company so... invoice must be named for C2C FR and it's C2C FR who should pay for sure.

On the other side... could Joel make a purchase order? On his name? Who gives permisions to contacts inside a company to make a purchase order? Joel could buy a good for C2C FR but supplier will ALWAYS make the invoice on the name of C2C FR even if contact to receive it was Joel or Luc or Fabien or all of them.

It's same concept in all documents.

[Stéphane Bidoul (Acsone) (sbi)]

Don't you think that in the end, this is more a backward compatibility issue than a data model correctness issue?

Whatever the way we look at it, it is undeniable that 7.0 has changed the semantics of the partner_id field on business documents. And that has deep impacts everywhere.

Many good reasons for the change have been explained, but semantics changes must be made explicit by changing names. If this field had received any other name than partner_id (party_id, whatever), it would have been much easier to preserve backward compatibility to a great extend by (re)introducing partner_id as a read-only field.

IMHO, given the huge impact of this semantics change in community modules (and certified modules alike), preserving backward compatibility is totally worth an exception to the stable schema policy.

[Nhomar - Vauxoo (nhomar)]

O think several cases are related to the leak of documentations o both
sides community and fabien's team.

One thing is important to understand, technically speaking Imho have the
same table_ model_ (correctly segmented even I postgres side) with all
entities (users, partners, contacts, and so on) is not the problem.

The main issue is consider that in legal documents you continue afirming
it is a related field and not a saved field.

Btw.

I am now in an important meeting wit one of our biggest (OPW) Customers
showing the case and the impact in the migration and proccess, I think
resume all the business cases here presented v6.1 vs v7.0 and Fabien giving
us a feedback over all the spectrum should help everybody "What do you
think?".

IOH.

BTW.... In terms of migration @Fabien where will be recorded in our
databases the invoice address on all business documents?

Thank for all the effort ..... But no thanks for the headache ;-)

Written from my android
On Apr 10, 2013 3:46 PM, "Stéphane Bidoul (Acsone)" <
<email address hidden>> wrote:

> Don't you think that in the end, this is more a backward compatibility
> issue than a data model correctness issue?
>
> Whatever the way we look at it, it is undeniable that 7.0 has changed
> the semantics of the partner_id field on business documents. And that
> has deep impacts everywhere.
>
> Many good reasons for the change have been explained, but semantics
> changes must be made explicit by changing names. If this field had
> received any other name than partner_id (party_id, whatever), it would
> have been much easier to preserve backward compatibility to a great
> extend by (re)introducing partner_id as a read-only field.
>
> IMHO, given the huge impact of this semantics change in community
> modules (and certified modules alike), preserving backward compatibility
> is totally worth an exception to the stable schema policy.
>
> --
> 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" ...

[Fabien (Open ERP) (fp-tinyerp)]

On 10/04/13 21:30, Maxime Chambreuil (http://www.savoirfairelinux.com)
wrote:
> @ Fabien
>
> On the performance perspective, I would be interested to know how you
> solution behave.
>
> I foresee that your solution will save time on the write but increase on
> reporting.

It's not an issue. You can do a fields.related() with store=True.

> Raphaël solution will take more time on the write (but won't be
> significant, it is just one field to compute), but will be faster when
> reporting (no need to look for the 1st commercial entity id).

As we said, we think adding a field (Raphaël's solution) was not the
real issue. We did not followed his proposition because we think it does
not fix all business cases, it does not handle the other problems, it
does not respect the direction foreseen in v7 which may break some
modules unless we do huge changes in several models.

> Other scenario for you: how do you handle the case where Joël is now
> working for C2C CH ? Will its claim follow to C2C CH or will it stay
> with C2C FR ? From a user standpoint, I expect the claim to stay with
> C2C FR.
>

If Joël start working for another company:
   - you have to create another Joël in the new company or
   - you install base_contact to handle this scenario

But changing the company of Joël may create inconsistencies in
the DB (same than in v6.1 and Raphaël's proposition)

Fabien

[Guewen Baconnier @ Camptocamp (gbaconnier-c2c)]

On 04/10/2013 09:11 PM, Fabien (Open ERP) wrote:
>> Now trying to hide the conceptual errors
>> with a model that is conceptually bad anyway.
>
> This is where we disagree. We think the data model in v7 is good. (even
> better than in v6.1).
>
>
> On the invoice, we have a field partner_id which contains "Joël,
> Camptocamp".
> Your claim is that the data model is not good because it can not work
> without
> another field "Camptocamp". (let's call it partner_commercial_id)
>
> This field must be:
> - related: it's implementation is one line:
> fields.related('partner_id','commercial_id')
> - readonly: no other value than "Camptocamp" is possible
>
> It's clear that adding a readonly function field:
> - DOES NOT change anything to the data model (you just add a redundancy)
> - DOES NOT change anything to what you can do in the code, instead of
> doing
> invoice.partner_id.commercial_id, you would do:
> invoice.partner_commercial_id

You hit the point, Fabien.
Nobody said that the new model can not work, with some changes in some
places. But you are in the future.
We are facing the reality and we are in the present.

Your model *is not backward compatible*, and today, the addons have not
been changed to be compatible with your new data model.
Do the official addons have been modified to use
'partner_id.commercial_id' instead of 'partner_id'? I don't think so
(not only the invoice)
Do the 3000 community addons you are so proud of have been modified to
use it? No

Worse, the field is still called 'partner_id', so the addons will still
behave, but incorrectly.

The whole point was to say: if we ensure that we only have a 'commercial
entity' in the field 'partner_id', we are backward compatible.

Summarizing:
Yesterday (6.1) in partner_id: only 'commercial entity', modules using
them as commercial entities
Today (7.0) in partner_id: any type of partner, but modules still using
them, wrongly, as commercial entities

Do you see the problem?

>
>
> Your extra field is just a technical artifact to allow group_by on
> "commercial
> entities" in invoices rather than "invoiced entities". Nothing more.
>
> We agree it's a good feature (we proposed it for v8 and, now we agree to
> do a
> module for v7) but: it's not a legal requirement, nor does it change
> anything to
> the data model (as you just add a function field)
>
>
> To be clear, we did one mistake in v7; the contacts did not inherited
> from accounting
> fields from their companies (like pricelists, account receivable) We
> should have
> done what we did for the address for these fields too. We missed that
> point. It's a
> 20 lines patch. The rest is just misunderstandings and fears.
>
>> And in any case, such semantic and conceptual changes should have been
>> debated explicitly at least 1 year before a version, certainly not 100
>> days after the "LTS" release.
>
> Yes, I do agree. We did not received enough feedback from the community
> on the version 7, during the RC phase. We got much more feedback for v6.1.
>
> These may be the reasons:
> - We did less Release Candidate for v7 (1) than 6.1. (3)
> - partners were expecting the v6.1 more than the v7 beca...

[Fabien (Open ERP) (fp-tinyerp)]

Ana,

Don't make we wrong. The change in the semantic in v7 is the following:

  - In v6.1, "Joël, Camptocamp" was an address of Camptocamp.
  - In v7, "Joël, Camptocamp" is a person representing the "Camptocamp"
    company.

It does not mean that the invoice do not belong to Camptocamp. The
invoice belong to Camptocamp (partner_commercial_id): it's Camptocamp
that will pay it and Camptocamp will be printed on all legal reports.

It means that someone representing the company "Joël" can do a purchase
for the company and it's not the same situation than having a purchase
in the name of Camptocamp. (e.g. in Belgium you can break a contract if
you can proove that Joël did not had the right to sign for Camptocamp)

In terms of data model, it does not change anything as:
  - on the invoice, you have the link to both (directly or indirectly,
    depending if we add a related field)
  - on Joël, you have the link to what he purchased
  - on Camptocamp, you have two fields:
      - invoice_ids: what C2C bought directly
      - invoice_commercial_ids: what C2C and Joël bought (or child_of
        if you don't want the related field)

Note also that "partner_id, address_id" is not exactly the same than
"partner_commercial_id, partner_id". The semantic really changed, it's
not just a switch in field names.

For different reasons:
  - partner_id is the main field on an invoice in v6.1. In v7,
partner_id is also the main field. The only one you should record in the
interface.
  - partner_id -> address_id in v6.1 is different than
"partner_commercial_id -> partner_id". E.G. in v7: in B2C,
partner_commercial_id=partner_id, in most B2B
partner_commercial_id=partner_id.parent_id, in b2B or B2C when using
hierarchies, you can have: partner_commercial_id =
partner_id.parent_id.parent_id.id

On 04/10/2013 09:56 PM, Ana Juaristi Olalde wrote:
> @Fabien:
> So... No, I think the record belongs to Joël, not C2C FR and certainly not to
> both. In other words: an invoice to "Joël, C2C" is not the same than an
> invoice to "C2C". (e.g. you send the invoice to <email address hidden>, not
> <email address hidden>)
> --> THIS IS JUST THE PROBLEM. An Invoice, belongs ALWAYS to C2C FR because your fiscal legal entity is C2C FR. Additionally you will send the invoice to Joêl or you could send to several other accountant contacts if you need, or even you could sent to general "info@" because it's the main email for company and additionally to contacts that you want to send. You are giving priority to communications instead of giving priority to legal requirement. Communications can be built as final customer decides. Even if you assume there is only one financial contact this assumtion can be wrong from final customer side but he can NEVER deny that invoice has to be behind the name of legal fiscal entity as is written by low in most countries I know.
>
> If you make the record belong to both, you will have others problems
> like count(one2many) that will return twice the real number of records
> --> This is not exactly like that because if you have got 2 fields on documents you will always count sum(partner_id). You will always have correct number if you set correctly the domain depending...

[Eckhard Schwarzat (e-schwarzat)]

Fabien,

Thanks for the clarification.

As a suggestion to move forward on this discussion, a side-by-side comparison of the logical and physical data model of version 6.1 and version 7 would be extremely helpful.
Maybe this documentation exists already somewhere, so my apologies in advance, should I have missed it.
(SQL Power Architect is an excellent open source tool for such a purpose for example.)

Call me old-fashioned, but coming from a Business Intelligence background, I found this approach the most rewarding.
That would give us as partners as well as maintainers / creators of modules the chance to get a far clearer picture.

Cheers,
Eckhard.

[Fabien (Open ERP) (fp-tinyerp)]

> Your model *is not backward compatible*, and today, the addons have not
> been changed to be compatible with your new data model.
> Do the official addons have been modified to use
> 'partner_id.commercial_id' instead of 'partner_id'?

There are probably some bugs that we may have missed, but we do think
the data model is good and we don't think there are a lot of bugs.

So, if you agree on the semantic and the data model, let's move forward
and test to check if there are bugs or not. If you find dozens of bugs,
we may change our mind otherwise, it's better to just fix what we may
have missed.

I guess Olivier will have finished it's implementation today (he
finished yesterday, but he still had to develop the extra module with
the extra related field)

My proposition is to test Olivier's branch once it's cleaned.

> Do the 3000 community addons you are so proud of have been modified to
> use it? No

Yes, all modules have to be slightly adapted to v7, not only because of
this change. 100% of the objects and views have been modified. It's a
lot of small changes, but not that difficult to adapt. So, whether we
would have done this change or not, porting a module to v7 always
require adaptation.

We understand that breaking compatibility between versions is a real
pain. (it's also a strong pain & cost for us) We usually try to avoid
this when we can.

But sometimes it's better to promote evolution rather than sticking to
an old model. We do it only if the new model is worth the change. We do
think that the new model is a strong improvement (B2C compatible, better
usability, hierarchies handled efficiently and compatible with
base_contact's semantic -> these are 4 solid arguments that are worth
the evolution)

> Worse, the field is still called 'partner_id', so the addons will still
> behave, but incorrectly.
> The whole point was to say: if we ensure that we only have a 'commercial
> entity' in the field 'partner_id', we are backward compatible.
> Summarizing:
> Yesterday (6.1) in partner_id: only 'commercial entity', modules using
> them as commercial entities
> Today (7.0) in partner_id: any type of partner, but modules still using
> them, wrongly, as commercial entities
>
> Do you see the problem?

Yes, but I do not think it's just a problem of naming fields.

There are lots of small others reasons that will make you to adapt your
module if you want to port to v7. So, in any case you will have to adapt
your module.

As it's done now, we prefer to not change the stable release. (and a
change in nearly all official modules)

We also prefer not to have partner_id, address_id on the invoice as this
does not reflect the new semantic:
  -> Joël is not an address anymore, it's a company representative.
  -> the main field is partner_id which is logic (the other one if just
     a function field)

Thanks,

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

[Ana Juaristi Olalde (ajuaristio)]

@fabien:

You are not understanding our point. We DO understand yours but we think it's still incorrect.

Example:
C2C FR: on table partner, ID=1
Joel: on table partner, ID=2, type=contact, address_id = 3, partner_id =1
Invoice_address: on table partner, ID=3, type=address, partner_id =1

This is OUR aproach.
NOW... on documents:
Invoice: Partner_id =1, many2one partners table
               Address_id=3, many2one partner table
               contact_id=2, many2one partner table

The aproach you are giving:
NEW field commercial_entity_id
C2C FR: on table partner, ID=1, commercial_entity_id =1
Joel: on table partner, ID=2, commercial_entity_id =1
Invoice_address: on table partner, ID=3, commercial_entity_id=1
On this point: Commercial_entity_id DOES NOT EXISTS yet, so you are including a new key base field that YOU DON'T NEED to fix your data model.

Now... on documents:
Invoice: Partner_id=2, commercial_entity_id=1
               Address_id=¿?¿?¿?¿? --> 2 or 1¿?¿?
               contact_id = ¿?¿?¿?
Your aproach will need much longer time to make stable, you are breaking background compatibility. You can have just same functionality you need simply adding extra many2one or many2many fields on documents you need using first aproach, even the model can be easily extended by community modules, if you set correctly partner/party table type field and set correctly domains on documents... That's all. Where is the problem so?

[Joël Grand-Guillaume @ camptocamp (jgrandguillaume-c2c)]

@Fabien & @odony

Well, I start to be desperate here honestly... Let's move this forward. WE NEED A CONCRETE SOLUTION, not arguments. As you said Fabien, lets talk about FACTD and BUGS. I remind you that I took the time to test your suggested solution and provide a FEED-BACK about : what's good, what's still a bug, what's still unsolved... See #34: https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/34

=> I receive back from you print screens instead of solution/way to solve the remaining trouble faced/discovered. This is not the way we will solve this problem. I try once again to be exhaustive on all points raised that need a solution, please prove us you get an answer for each of them with what's suggested:

 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...
=> this is a bug I think and can be fixed allowing to invoice Joel in Invoice (mean allow to invoice "invoicing" partner"), you agree ?

 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 ?
=> This is a bug and can be fixed, you agree ?

 C) In the case invoice are related to "Joel (Camptocamp)", the sales turnover for Camptocamp is not correct (from Reporting -> Invoice analysis menu, not from grouping invoices,...). 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 as part of Camptocamp history, nor it'll group them properly using the Group by... Child of stuff isn't good because of performance issue (try grouping even the account.move.line when you have 30K => it doesn't work in v7.0 and there's no child of here) + very difficult to implement when using third party reporting system + Raphaël is right : https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/85
=> This is not a "technical" bug but a huge/not acceptable usability issue. Only solution is to store in DB the partner_id + contact_id in the way old schema implemented it. Don't care if you name them commercial_whatever_id. We need it in DB for external system + group by + perfs reasons that's all.

D) We still cannot invoice a specific address of a specific company... We have (and others too) some complex structure to invoice, like the states, big university and even with those corrections, we do not solve this major issue. You have:
  - Group Company XY
     - Company A
         - Department A, Contact 1
         - Department A, Contact 2
     - Company B
         - Department B, Contact 3
 => This is mandatory that you ca...

[Olivier Dony (Odoo) (odo-openerp)]

Thanks everyone for the tests and feedback. The 2 branches have been updated with several important changes (see also the updated descriptions on the MPs):

In addons:

1. revert the modified domain set on the partner field of Invoices - this was inconsistent with the rest of the system: it must be possible to invoice a contact everywhere. Concerning this, please note that Fabien's explanation in comment #50 was incorrect because we want to be able to create invoices for any contact. What happens is that you can configure the contact type on your partners so that the correct "invoice contact/department" is automatically selected regardless of the contact to which you sell. But you can still manually invoice any contact and the rest of the accounting flows will still be correct (and the reporting too).

2. fix issue detected by Joël Grand-Guillaume in comment #34 of bug 1160365: when invoicing after delivery, the invoicing contact/address must be used rather than the main customer. Tests updated accordingly.

3. add new module "account_report_company": this module adds an extra stored field "parent_commercial_id" on Invoices to make reporting/aggregating by partner easier in the Invoice list and in the Invoice Analysis report. This module is expected to be merged in the main account module in the next major release. The module can be installed without any risk on any existing 7.0 database.
Yes we know that many would have preferred to use an extra contact_id field and make the partner_id field refer to the "commercial entity", but this is actually inconsistent with the rest of the model: everywhere in OpenERP 7.0 we'll allow a "contact" level of granularity, we must not change that for a single case of reporting. It would also change the logic in a completely incompatible way depending on whether the module is installed or not, which is a lot worse.
Keep in mind that this module is added only to make reporting per Company easier on Invoices - not to alter the core level of granularity of partners in OpenERP 7.0.

In server:

3. res.partner.address_get() now defaults to the partner being looked up rather than company when no match is found at all and no "default" exists. This avoids losing the contact info on invoices when a new contact+company pair is created.

4. fix incorrect autosync of `type` field along with other address fields - a different `type` makes sense even when address is inherited because they can have different name/email/phones/etc.

5. res.partner.name_search: make sure companies always come before contacts when both match, to make selection more predictable.

6. embedded contact creation mini-form was updated to include the address fields and the `type` field

These branches are updated on runbot.openerp.com, please test them to see if you can still find specific issues, so we can proceed further.

Thanks a lot!

[Olivier Dony (Odoo) (odo-openerp)]

(Sorry the numbering of the items is wrong in previous comment, noticed it just after posting)

[Olivier Dony (Odoo) (odo-openerp)]

Some more precisions regarding Joël's questions...

On 04/11/2013 12:18 PM, Joël Grand-Guillaume @ camptocamp wrote:
> 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... => this is a bug I
> think and can be fixed allowing to invoice Joel in Invoice (mean allow to
> invoice "invoicing" partner"), you agree ?

Yes, that was inconsistent in the proposed solution and in comment #50. The
domain change was reverted on invoices.

> 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 ? => This is a bug
> and can be fixed, you agree ?

Yes that was clearly a bug as well. It existed in previous versions (the
invoice address was not copied but instead reset), but was only apparent if
using an invoice address that was not the default one selected by the onchange.
This is fixed in the sale_stock module.

> C) In the case invoice are related to "Joel (Camptocamp)", the sales
> turnover for Camptocamp is not correct (from Reporting -> Invoice analysis
> menu, not from grouping invoices,...).

This is handled by the extra "account_report_company" module, to be merged in
account in trunk, and which will allow grouping and analyzing invoices per
"Commercial Entity".

We only need this in Invoices because the contact-level granularity is
explicitly overridden on the Journal Entries, and because Invoices are a key
reporting area in any business. For all other cases we think the contact-level
granularity will be correct and expected.

As Fabien mentioned, there can be cases where it will be useful to allow search
criterions on "Partner" to also match the contacts (child_of), but these should
only be for usability purposes.

Performance-wise, the "child_of" operator used for a Partner criterions only
depends on the depth of the partner hierarchy, not the number of business
documents. For very deep hierarchies it can even be made O(1) by enabling
_parent_store on res.partner, if ever needed.

> D) We still cannot invoice a specific address of a specific company... We
> have (and others too) some complex structure to invoice, like the states,
> big university and even with those corrections, we do not solve this major
> issue. You have:
> - Group Company XY
> - Company A
> - Department A, Contact 1
> - Department A, Contact 2
> - Company B
> - Department B, Contact 3
> => This is mandatory that you can invoice Company A, for submission to
> "Department A, Contact 1" or "Department A, Contact 2". We do need two
> fields on the invoice... Because even if properties are correctly set (the
> only bug you saw and correct here), we can still make invoice addressed to
> Contact ...

[Ana Juaristi Olalde (ajuaristio)]

So, everything is said. Problem is that you still think that correct
granularity level is contact, since people all over the world think that
correct level is partner.
IMHO i still think it is a big mistake changing level of granularity,
giving priority to a secondary entity as it is contact instead of first
level granularity entity as it is company.
But sentence has been written and it seems there will not be strategy
change. So there is nothing more we can do. It is a pity.
Thank you for your time and detailed explnations.
El 11/04/2013 20:31, "Olivier Dony (OpenERP)" <email address hidden>
escribió:

> Some more precisions regarding Joël's questions...
>
> On 04/11/2013 12:18 PM, Joël Grand-Guillaume @ camptocamp wrote:
> > 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... => this is a bug I
> > think and can be fixed allowing to invoice Joel in Invoice (mean allow to
> > invoice "invoicing" partner"), you agree ?
>
> Yes, that was inconsistent in the proposed solution and in comment #50. The
> domain change was reverted on invoices.
>
>
> > 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 ? => This is a
> bug
> > and can be fixed, you agree ?
>
> Yes that was clearly a bug as well. It existed in previous versions (the
> invoice address was not copied but instead reset), but was only apparent if
> using an invoice address that was not the default one selected by the
> onchange.
> This is fixed in the sale_stock module.
>
>
> > C) In the case invoice are related to "Joel (Camptocamp)", the sales
> > turnover for Camptocamp is not correct (from Reporting -> Invoice
> analysis
> > menu, not from grouping invoices,...).
>
> This is handled by the extra "account_report_company" module, to be merged
> in
> account in trunk, and which will allow grouping and analyzing invoices per
> "Commercial Entity".
>
> We only need this in Invoices because the contact-level granularity is
> explicitly overridden on the Journal Entries, and because Invoices are a
> key
> reporting area in any business. For all other cases we think the
> contact-level
> granularity will be correct and expected.
>
> As Fabien mentioned, there can be cases where it will be useful to allow
> search
> criterions on "Partner" to also match the contacts (child_of), but these
> should
> only be for usability purposes.
>
> Performance-wise, the "child_of" operator used for a Partner criterions
> only
> depends on the depth of the partner hierarchy, not the number of business
> documents. For very deep hierarchies it can even be made O(1) by enabling
> _parent_store on res.partner, if ever needed.
>
>
> > D) We still cannot...

[Jacques-Etienne Baudoux (jbaudoux)]

Hi Olivier,
I've just done some tests with the branch on runbot (http://7-0-fix-contact-company-handling-6813.runbot.openerp.com/)
Here are the issues I found:
1/ Supplier property is not propagated.
1a/ When you create a supplier contact and then create from that contact the company and the invoice contact of that company, only the contact is marked as supplier.
1b/ When you create a supplier company and then create from that company a contact and the invoice contact of that company, only the company is marked as supplier. As the contact view is simplified, you are forced to go to customer, search for your suppliers and mark them as suppliers. By the way, you cannot search on a name in the customer/supplier views in accounting.
2/ When you create a Sales quotation for a contact, and generate a customer invoice, the invoicing contact of the company is selected. When you create a RFQ for a contact, and generate a supplier invoice, the initial contact is kept, I expected to have to invoicing contact.
3/ Name search issue: I have a company named "tje4-supplier-company" with a contact named "tje4-supplier-contact" and an invoicing contact named "Mme tje4-supplier-invoice". When I enter "tje" in the name_search, it show the company, then the invoicing contact, but it does not show the contact. I would expect name_search to return the 3, I prefer that order :
on RFQ, the contact, then the company, then the invoicing contact ; on supplier invoice, the invoicing contact, then the company, then the contact.
4/ When you create an opportunity, in the 6.1, there is a company field and a contact field. This allows you to select or create the company, then specify the contact (I admit this does not work with base_contact). With the 7.0, you directly create the contact, then you need to leave the opportunity screen to edit the contact and select or create the company of that contact. When you modify or fill the email field on the opportunity, it doesn't affect the email of the contact (I don't remember this worked before, but would be good to fix it).
5/ In 6.1, there was an history tab on the opportunity allowing in 1 click to see everything of what happened with that opportunity. In 7.0, you need to click on the meeting button to reach the meeting calendar view, then you still have to switch to list view, search for the name of the contact by typing his name (that you have to remember with the right spelling), select you want to search by Attendee (that's not the default search), go back to the opportunity with the breadcrumb, then continue with next button to see the calls .... Then remember and consolidate all that in your head. This is NOT AT ALL a usability improvement!!! Do not do that everywhere (https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/78) and put back that history tab.

Regards,
J-E

[Olivier Dony (Odoo) (odo-openerp)]

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

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

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

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

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

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

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

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

Thanks again!

[Fabien (Open ERP) (fp-tinyerp)]

Ana,

Can you try the branch provided by Olivier with your customer use cases?
I am interrested to know which scenario is not good, according to you.

Sent from my iPad

On 11 Apr 2013, at 22:09, Ana Juaristi Olalde <email address hidden> wrote:

> So, everything is said. Problem is that you still think that correct
> granularity level is contact, since people all over the world think that
> correct level is partner.
> IMHO i still think it is a big mistake changing level of granularity,
> giving priority to a secondary entity as it is contact instead of first
> level granularity entity as it is company.
> But sentence has been written and it seems there will not be strategy
> change. So there is nothing more we can do. It is a pity.
> Thank you for your time and detailed explnations.
> El 11/04/2013 20:31, "Olivier Dony (OpenERP)" <email address hidden>
> escribió:
>
>> Some more precisions regarding Joël's questions...
>>
>> On 04/11/2013 12:18 PM, Joël Grand-Guillaume @ camptocamp wrote:
>>> 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... => this is a bug I
>>> think and can be fixed allowing to invoice Joel in Invoice (mean allow to
>>> invoice "invoicing" partner"), you agree ?
>>
>> Yes, that was inconsistent in the proposed solution and in comment #50. The
>> domain change was reverted on invoices.
>>
>>
>>> 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 ? => This is a
>> bug
>>> and can be fixed, you agree ?
>>
>> Yes that was clearly a bug as well. It existed in previous versions (the
>> invoice address was not copied but instead reset), but was only apparent if
>> using an invoice address that was not the default one selected by the
>> onchange.
>> This is fixed in the sale_stock module.
>>
>>
>>> C) In the case invoice are related to "Joel (Camptocamp)", the sales
>>> turnover for Camptocamp is not correct (from Reporting -> Invoice
>> analysis
>>> menu, not from grouping invoices,...).
>>
>> This is handled by the extra "account_report_company" module, to be merged
>> in
>> account in trunk, and which will allow grouping and analyzing invoices per
>> "Commercial Entity".
>>
>> We only need this in Invoices because the contact-level granularity is
>> explicitly overridden on the Journal Entries, and because Invoices are a
>> key
>> reporting area in any business. For all other cases we think the
>> contact-level
>> granularity will be correct and expected.
>>
>> As Fabien mentioned, there can be cases where it will be useful to allow
>> search
>> criterions on "Partner" to also match the contacts (child_of), but these
>> should
>> only be for usability...

[Ana Juaristi Olalde (ajuaristio)]

Fabien... For sure we will do that and give you feedback.
But... Even if I would like to be mistaken, this is my point...

We DO need an ERP, ok? An ERP main object always is Legal Entity.
Everything in an ERP is related to Legal Entity, begining from Purchases,
pickins, invoices, accounting, and... even Claims or Opportunities are
related to a Partner/Company whatever you want to name it.
You only need contacts or addresses for communications, nothing more and
even, if you try setting a contact somewhere, this contact can change for
several reasons inside a Company as I told before (Hired, hollidays, fired,
died... ). Contact is not UNIQUE inside a company even a single contact
could be related to different companies. Contacts can be changed one with
other but legal entity never change. It's always the same. It's UNIQUE
always even if you can set different hierarchies between them. So... when
modeling an IT system if focus is not correct, everything will go wrong.

On the other side, what you did is not another version but another ERP with
a different focus different granularity, so on this case, i think it will
be quite difficult trying to cover all possible impacts and hidden
consecuences in a short time.

That's my point and I say again: I wish I'm mistaken.

Thank you again.
Ana

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

> Ana,
>
> Can you try the branch provided by Olivier with your customer use cases?
> I am interrested to know which scenario is not good, according to you.
>
> Sent from my iPad
>
> On 11 Apr 2013, at 22:09, Ana Juaristi Olalde <email address hidden>
> wrote:
>
> > So, everything is said. Problem is that you still think that correct
> > granularity level is contact, since people all over the world think that
> > correct level is partner.
> > IMHO i still think it is a big mistake changing level of granularity,
> > giving priority to a secondary entity as it is contact instead of first
> > level granularity entity as it is company.
> > But sentence has been written and it seems there will not be strategy
> > change. So there is nothing more we can do. It is a pity.
> > Thank you for your time and detailed explnations.
> > El 11/04/2013 20:31, "Olivier Dony (OpenERP)" <
> <email address hidden>>
> > escribió:
> >
> >> Some more precisions regarding Joël's questions...
> >>
> >> On 04/11/2013 12:18 PM, Joël Grand-Guillaume @ camptocamp wrote:
> >>> 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... => this is a
> bug I
> >>> think and can be fixed allowing to invoice Joel in Invoice (mean allow
> to
> >>> invoice "invoicing" partner"), you agree ?
> >>
> >> Yes, that was inconsistent in the proposed solution and in comment #50.
> The
> >> domain change was reverted on invoices.
> >>
> >>
> >>> B) When making a SO to Camptocamp with "invoice from delivery", confirm
> >> it,
> >>> confirm de...

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

E few more protestations against what is being decided by Fabien and Olivier:

1)
indeed: just like as Ana said, in an ERP, what matters the most are legal/commercial entities. Contacts may be interesting to store, but if I should choose between two keys of analysis and relating things, the commercial entity is definitely what matters the most. Loosing in general that key at the profit of of the contact and making the commercial entity the exception to have again is total nonsense for an ERP. This is all the more nonsense that during 8 years OpenERP has been made and tested this way vs not even tested once in production after this half un-assumed semantic change from the very last months of wild development. This kind of bug just proves it.

2)
Olivier claims that OpenERP SA proposition is less invasive than the two keys one that one of my module at https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/27 that impacts every business object. Excuse me to say it: "this is bullshit". All right, my module adds a contact_id key that the developer may need to consider or explicitly opt out what a big deal for a contact field that has almost never been used critically before...
My module adding a contact_id key automatically on all objects with a partner_id isn't something more difficult to handle than OpenERP ORM adding a create_date or a write_date on every object.
The view customization to hide partner_id and show contact_id can be seen as just having a new "contact" widget setting both keys appropriately but hiding partner_id in easy edition mode.

Hell what is more important: put in danger all the proven critical ERP features that made OpenERP reputation all these years till 6.1 included and totally rely on partner_id being the commercial/legal entity OR saying OpenERP SA should just review a bit the 4-5 new social eye candy features introduced in v7 (never tested well in production, hardly even wanted as a priority by OpenERP users)?

What is more critical: not being able to consolidate, filter or relate any business any data by customer/supplier OR sending an email by mistake to the email of company instead of the email of a contact?

3) by refusing to apply a systematic solution to the problem: you are introducing a dangerous amount of entropy and inconsistencies all over the place. Indeed: some objects will have the 2 keys: a sale order historically and now an invoice with your patch module after we complained mostly about invoicing specifically (we were just pointing the most obvious issue, it doesn't mean it's the only one, we have been clear about that). But for all other objects, the randomness if partner_id is a company or just a contact of it will continue with no guarantee you can consolidate, filter or relate on these chaotic partner_id keys.

That means, by refusing to adopt a systematic solution, you are just moving the border between order and chaos a bit further where users didn't complained yet. But you are not fixing the problem at all! You are just moving the issue to a new random, inconsistent and moving place. As users and integrators will keep discovering bugs and complaining about these new places, chances a...

[Ana Juaristi Olalde (ajuaristio)]

Raphaël, you could said it louder but not clearer. +1 to all your comments.
So.. Let's try again.

Imaging this case of use:

John Doe works for ACME, SA.
John Doe buys a good for ACME, SA.
Our company makes a sale order for John Doe working for ACME, SA.
We are sending goods after one month Jon Doe asked for those goods so we
will expend almost 1 month to send the invoice to John Doe. Curiously, John
Doe left ACME, SA and was contracted by CAEM, SA who casually is also our
customer.
How do we handle with this aproach on 7.0?
1. We have got to create John Doe for CAEM, or worst, change John Doe
company asigning now CAEM, instead of ACME. So.. if user does that... What
will be the company related to invoice? CAEM? ACME?
2. If we create both different John Doe contact... sameway first invoice is
going to an incorrect contact because John Doe is not working more for
ACME.
3. If we just move company... I don't know what happens. I'm lost,
because... How this will affect to sale order? or pickings? Or statistics?

Now.. let me handle same aproach with 6.1
1. Sale order is in the name of ACME. Additionally (if we need) could set
John Doe as related contact for Acme.
2. If John Doe leaves... what happens? NOTHING at all. User does not need
being worried about correct contacts because nothing change.
3. Sale order will be always related to ACME, Pickings will be related to
ACME and Invoices will be related to ACME. Additionally if we want
correctly set John Doe is now working for CAEM... just change the contact
company on contacts... it's done.

I feel really silly trying to explain this to someone. I can not realize
how anybody can not see this aproach...

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

> E few more protestations against what is being decided by Fabien and
> Olivier:
>
> 1)
> indeed: just like as Ana said, in an ERP, what matters the most are
> legal/commercial entities. Contacts may be interesting to store, but if I
> should choose between two keys of analysis and relating things, the
> commercial entity is definitely what matters the most. Loosing in general
> that key at the profit of of the contact and making the commercial entity
> the exception to have again is total nonsense for an ERP. This is all the
> more nonsense that during 8 years OpenERP has been made and tested this way
> vs not even tested once in production after this half un-assumed semantic
> change from the very last months of wild development. This kind of bug just
> proves it.
>
> 2)
> Olivier claims that OpenERP SA proposition is less invasive than the two
> keys one that one of my module at
> https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/27that impacts every business object. Excuse me to say it: "this is
> bullshit". All right, my module adds a contact_id key that the developer
> may need to consider or explicitly opt out what a big deal for a contact
> field that has almost never been used critically before...
> My module adding a contact_id key automatically on all objects with a
> partner_id isn't something more difficult to handle than OpenERP ORM adding
> a create_date or a write_date on every o...

[Fabien (Open ERP) (fp-tinyerp)]

Ana,

My reply to your scenario bellow.

> John Doe works for ACME, SA.
> John Doe buys a good for ACME, SA.
> Our company makes a sale order for John Doe working for ACME, SA.
> We are sending goods after one month Jon Doe asked for those goods so we
> will expend almost 1 month to send the invoice to John Doe. Curiously, John
> Doe left ACME, SA and was contracted by CAEM, SA who casually is also our
> customer.
> How do we handle with this aproach on 7.0?
> 1. We have got to create John Doe for CAEM, or worst, change John Doe
> company asigning now CAEM, instead of ACME. So.. if user does that... What
> will be the company related to invoice? CAEM? ACME?
> 2. If we create both different John Doe contact... sameway first invoice is
> going to an incorrect contact because John Doe is not working more for
> ACME.
> 3. If we just move company... I don't know what happens. I'm lost,
> because... How this will affect to sale order? or pickings? Or statistics?
>
> Now.. let me handle same aproach with 6.1
> 1. Sale order is in the name of ACME. Additionally (if we need) could set
> John Doe as related contact for Acme.
> 2. If John Doe leaves... what happens? NOTHING at all. User does not need
> being worried about correct contacts because nothing change.
> 3. Sale order will be always related to ACME, Pickings will be related to
> ACME and Invoices will be related to ACME. Additionally if we want
> correctly set John Doe is now working for CAEM... just change the contact
> company on contacts... it's done.

Please, Ana.

Please do test Olivier's branch and compare with v6.1 before judging.
You will notice that both versions produces the same result: documents
for external communications and forms for internal usage.

The behaviour is exactly the same in v6.1 and Olivier's branch when
sending documents to customers:
  - When printing the document, the sale order/invoice is sent to John
Doe's address (not to ACME's one) [*]
  - When sending by email, it uses John Doe's address, not acme's one.
And this is the correct behaviour!

If John Doe leaves and if you do the mistake to change John Doe's
company and address, the behaviour is exactly the same in v6.1 and in v7
--> wrong result. Whether it's by email or by post, documents are sent
to the new John Doe's address.

As an additional note, can you imagine sending your quote or invoices to
<email address hidden>?
It has no sense to send document to the generic address of a company.
Try to send a quote to <email address hidden> :) You have to send quotes to
<email address hidden> otherwise your email/letter will be lost in the company.

If someone leave the company, most companies redirect their emails and
letters to the responsible that replaces him, so this is not a problem.

If you change the company a person is working for (instead of creating a
new contact in the new company), you will create:
  - inconsistencies in v6.1, you get on printed addresses:
      Old Company
      Person
      New Company Address
  - in v7, you do not get an inconsistency as the model ensure it's
always correct (but it's may be not what the user expected):
      New Company
      Person
      New Company Address
The v7 behaviour is cons...

[Olivier Dony (Odoo) (odo-openerp)]

Ana, in addition to what Fabien said, just imagine that you may not hear about
John leaving the company until the shipping has already be done and the invoice
sent. All the documents (paper and database) would of course still be correct!

In addition, what about `base_contact` (I think you use it a lot)?
-> In 6.1 with base_contact you could add a new work position for the "John
Doe" contact, and the old work position "John Doe working at ACME with email
<email address hidden> would still be untouched -> correct.
-> In 7.0 base_contact will also help you add an existing contact to the new
company, leaving the original contact "John Doe (ACME)" untouched -> correct.

[Fabien (Open ERP) (fp-tinyerp)]

Common Raphaël,
Let's be serious.

Is there anyone on this list that read Raphaël's code [1] and that can
seriously tell me he would like this code to be merged in OpenERP?

I am ready to pay a pack of beer to Akretion at the community meeting,
if they are 5 people in this list that can reply and write *honestly*:

  I read Raphaël's code and I think this should be merged in OpenERP.

[1]
http://bazaar.launchpad.net/~akretion-team/openobject-addons/akretion_b2b_unfck/files/head:/akretion_b2b_unfck/

On 04/12/2013 04:23 PM, Raphaël Valyi - http://www.akretion.com wrote:
> E few more protestations against what is being decided by Fabien and
> Olivier:
>
> 1)
> indeed: just like as Ana said, in an ERP, what matters the most are legal/commercial entities. Contacts may be interesting to store, but if I should choose between two keys of analysis and relating things, the commercial entity is definitely what matters the most. Loosing in general that key at the profit of of the contact and making the commercial entity the exception to have again is total nonsense for an ERP. This is all the more nonsense that during 8 years OpenERP has been made and tested this way vs not even tested once in production after this half un-assumed semantic change from the very last months of wild development. This kind of bug just proves it.
>
> 2)
> Olivier claims that OpenERP SA proposition is less invasive than the two keys one that one of my module at https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/27 that impacts every business object. Excuse me to say it: "this is bullshit". All right, my module adds a contact_id key that the developer may need to consider or explicitly opt out what a big deal for a contact field that has almost never been used critically before...
> My module adding a contact_id key automatically on all objects with a partner_id isn't something more difficult to handle than OpenERP ORM adding a create_date or a write_date on every object.
> The view customization to hide partner_id and show contact_id can be seen as just having a new "contact" widget setting both keys appropriately but hiding partner_id in easy edition mode.
>
> Hell what is more important: put in danger all the proven critical ERP
> features that made OpenERP reputation all these years till 6.1 included
> and totally rely on partner_id being the commercial/legal entity OR
> saying OpenERP SA should just review a bit the 4-5 new social eye candy
> features introduced in v7 (never tested well in production, hardly even
> wanted as a priority by OpenERP users)?
>
> What is more critical: not being able to consolidate, filter or relate
> any business any data by customer/supplier OR sending an email by
> mistake to the email of company instead of the email of a contact?
>
> 3) by refusing to apply a systematic solution to the problem: you are
> introducing a dangerous amount of entropy and inconsistencies all over
> the place. Indeed: some objects will have the 2 keys: a sale order
> historically and now an invoice with your patch module after we
> complained mostly about invoicing specifically (we were just pointing
> the most obvious issue, it doesn't...

[Fabien (Open ERP) (fp-tinyerp)]

For lazy people, here is the most interesting file:

http://bazaar.launchpad.net/~akretion-team/openobject-addons/akretion_b2b_unfck/view/head:/akretion_b2b_unfck/akretion_b2b_unfck.py

On 04/12/2013 07:47 PM, Fabien Pinckaers wrote:
> Common Raphaël,
> Let's be serious.
>
> Is there anyone on this list that read Raphaël's code [1] and that can
> seriously tell me he would like this code to be merged in OpenERP?
>
> I am ready to pay a pack of beer to Akretion at the community meeting,
> if they are 5 people in this list that can reply and write *honestly*:
>
> I read Raphaël's code and I think this should be merged in OpenERP.
>
>
>
> [1]
> http://bazaar.launchpad.net/~akretion-team/openobject-addons/akretion_b2b_unfck/files/head:/akretion_b2b_unfck/
>
>
>
>
> On 04/12/2013 04:23 PM, Raphaël Valyi - http://www.akretion.com wrote:
>> E few more protestations against what is being decided by Fabien and
>> Olivier:
>>
>> 1)
>> indeed: just like as Ana said, in an ERP, what matters the most are legal/commercial entities. Contacts may be interesting to store, but if I should choose between two keys of analysis and relating things, the commercial entity is definitely what matters the most. Loosing in general that key at the profit of of the contact and making the commercial entity the exception to have again is total nonsense for an ERP. This is all the more nonsense that during 8 years OpenERP has been made and tested this way vs not even tested once in production after this half un-assumed semantic change from the very last months of wild development. This kind of bug just proves it.
>>
>> 2)
>> Olivier claims that OpenERP SA proposition is less invasive than the two keys one that one of my module at https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/27 that impacts every business object. Excuse me to say it: "this is bullshit". All right, my module adds a contact_id key that the developer may need to consider or explicitly opt out what a big deal for a contact field that has almost never been used critically before...
>> My module adding a contact_id key automatically on all objects with a partner_id isn't something more difficult to handle than OpenERP ORM adding a create_date or a write_date on every object.
>> The view customization to hide partner_id and show contact_id can be seen as just having a new "contact" widget setting both keys appropriately but hiding partner_id in easy edition mode.
>>
>> Hell what is more important: put in danger all the proven critical ERP
>> features that made OpenERP reputation all these years till 6.1 included
>> and totally rely on partner_id being the commercial/legal entity OR
>> saying OpenERP SA should just review a bit the 4-5 new social eye candy
>> features introduced in v7 (never tested well in production, hardly even
>> wanted as a priority by OpenERP users)?
>>
>> What is more critical: not being able to consolidate, filter or relate
>> any business any data by customer/supplier OR sending an email by
>> mistake to the email of company instead of the email of a contact?
>>
>> 3) by refusing to apply a systematic solution to the problem: you are
>> introducing a dang...

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Again,

this is a monkey patch because I don't have commit right in the core, but
eventually that could be done in the core, just like you add say a
write_date/create_date automatically and patch the view just like you use
to transform XML attributes int javascript modifiers. That wouldn't shock
me any more than that.

May be we will get these 5 people here...

On Fri, Apr 12, 2013 at 2:51 PM, Fabien (Open ERP) <email address hidden> wrote:

> For lazy people, here is the most interesting file:
>
>
>
> http://bazaar.launchpad.net/~akretion-team/openobject-addons/akretion_b2b_unfck/view/head:/akretion_b2b_unfck/akretion_b2b_unfck.py
>
>
>
> On 04/12/2013 07:47 PM, Fabien Pinckaers wrote:
> > Common Raphaël,
> > Let's be serious.
> >
> > Is there anyone on this list that read Raphaël's code [1] and that can
> > seriously tell me he would like this code to be merged in OpenERP?
> >
> > I am ready to pay a pack of beer to Akretion at the community meeting,
> > if they are 5 people in this list that can reply and write *honestly*:
> >
> > I read Raphaël's code and I think this should be merged in OpenERP.
> >
> >
> >
> > [1]
> >
> http://bazaar.launchpad.net/~akretion-team/openobject-addons/akretion_b2b_unfck/files/head:/akretion_b2b_unfck/
> >
> >
> >
> >
> > On 04/12/2013 04:23 PM, Raphaël Valyi - http://www.akretion.com wrote:
> >> E few more protestations against what is being decided by Fabien and
> >> Olivier:
> >>
> >> 1)
> >> indeed: just like as Ana said, in an ERP, what matters the most are
> legal/commercial entities. Contacts may be interesting to store, but if I
> should choose between two keys of analysis and relating things, the
> commercial entity is definitely what matters the most. Loosing in general
> that key at the profit of of the contact and making the commercial entity
> the exception to have again is total nonsense for an ERP. This is all the
> more nonsense that during 8 years OpenERP has been made and tested this way
> vs not even tested once in production after this half un-assumed semantic
> change from the very last months of wild development. This kind of bug just
> proves it.
> >>
> >> 2)
> >> Olivier claims that OpenERP SA proposition is less invasive than the
> two keys one that one of my module at
> https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/27that impacts every business object. Excuse me to say it: "this is
> bullshit". All right, my module adds a contact_id key that the developer
> may need to consider or explicitly opt out what a big deal for a contact
> field that has almost never been used critically before...
> >> My module adding a contact_id key automatically on all objects with a
> partner_id isn't something more difficult to handle than OpenERP ORM adding
> a create_date or a write_date on every object.
> >> The view customization to hide partner_id and show contact_id can be
> seen as just having a new "contact" widget setting both keys appropriately
> but hiding partner_id in easy edition mode.
> >>
> >> Hell what is more important: put in danger all the proven critical ERP
> >> features that made OpenERP reputation all these years till 6.1 included
> >> and totally rely on partne...

[Mario Arias (the-clone-master)]

Raphaël's solution seems better than risking referential integrity by
depending on duplicating company's attributes into contacts....

Just one piece of code where this duplication is missed, and we are all
doomed...

I think that's one of the the points in using databases instead of plain
files, isn't it ?

Regards,
-Mario

On 04/12/2013 01:30 PM, Raphaël Valyi - http://www.akretion.com wrote:
> Again,
>
> this is a monkey patch because I don't have commit right in the core, but
> eventually that could be done in the core, just like you add say a
> write_date/create_date automatically and patch the view just like you use
> to transform XML attributes int javascript modifiers. That wouldn't shock
> me any more than that.
>
> May be we will get these 5 people here...
>
>
> On Fri, Apr 12, 2013 at 2:51 PM, Fabien (Open ERP) <email address hidden> wrote:
>
>> For lazy people, here is the most interesting file:
>>
>>
>>
>> http://bazaar.launchpad.net/~akretion-team/openobject-addons/akretion_b2b_unfck/view/head:/akretion_b2b_unfck/akretion_b2b_unfck.py
>>
>>
>>
>> On 04/12/2013 07:47 PM, Fabien Pinckaers wrote:
>>> Common Raphaël,
>>> Let's be serious.
>>>
>>> Is there anyone on this list that read Raphaël's code [1] and that can
>>> seriously tell me he would like this code to be merged in OpenERP?
>>>
>>> I am ready to pay a pack of beer to Akretion at the community meeting,
>>> if they are 5 people in this list that can reply and write *honestly*:
>>>
>>> I read Raphaël's code and I think this should be merged in OpenERP.
>>>
>>>
>>>
>>> [1]
>>>
>> http://bazaar.launchpad.net/~akretion-team/openobject-addons/akretion_b2b_unfck/files/head:/akretion_b2b_unfck/
>>>
>>>
>>>
>>> On 04/12/2013 04:23 PM, Raphaël Valyi - http://www.akretion.com wrote:
>>>> E few more protestations against what is being decided by Fabien and
>>>> Olivier:
>>>>
>>>> 1)
>>>> indeed: just like as Ana said, in an ERP, what matters the most are
>> legal/commercial entities. Contacts may be interesting to store, but if I
>> should choose between two keys of analysis and relating things, the
>> commercial entity is definitely what matters the most. Loosing in general
>> that key at the profit of of the contact and making the commercial entity
>> the exception to have again is total nonsense for an ERP. This is all the
>> more nonsense that during 8 years OpenERP has been made and tested this way
>> vs not even tested once in production after this half un-assumed semantic
>> change from the very last months of wild development. This kind of bug just
>> proves it.
>>>> 2)
>>>> Olivier claims that OpenERP SA proposition is less invasive than the
>> two keys one that one of my module at
>> https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/27that impacts every business object. Excuse me to say it: "this is
>> bullshit". All right, my module adds a contact_id key that the developer
>> may need to consider or explicitly opt out what a big deal for a contact
>> field that has almost never been used critically before...
>>>> My module adding a contact_id key automatically on all objects with a
>> partner_id isn't something more difficult to handle than OpenERP ORM ...

[Maxime Chambreuil (http://www.savoirfairelinux.com) (max3903)]

I read Raphaël's code and I think his idea deserve to be merged in OpenERP.

@ Fabien

Raphaël's code is a prototype, like you presented us version 7 last year. Would you merge your code as it was last year in the current code base ? Of course not. Why ? Because you required a year of development to meet your standards and merge it.

So be fair and give Raphaël and the community a month (I could have asked for a year ;) ) to improve this code and it will be ready to be merged. How does it sound ?

[Ana Juaristi Olalde (ajuaristio)]

OK... Testing as asked by Fabien in Runbot.

Sale order:
Customer ACME Company Walt disney studios 444444444 Orlando, FL 33333 United States
Invoice Address John Doe for Acme Company (ACME Company) John Doe Home Address 3838383838 Myhome, FL 2222 United States
Delivery Address Agrolait 69 rue de Namur 1300 Wavre Belgium

It seems quite extrange to be allowed sending goods to Agrolait when it's another partner, but... extremly it could be. (Bug easily can fixed including right domain on sale order)

Going further:
Picking is correctly set to Agrolait. Sales order printing is correctly printed but is showing also John Doe's home address.

Next step:
Create invoice from picking:
Customer John Doe for Acme Company (ACME Company) John Doe Home Address 3838383838 Myhome, FL 2222 United States
FOR ME THIS IS TOTALLY WRONG. INVOICE CONTACT is John DOE, but... INVOICE ADDRESS SHOULD BE the one from ACME
What am I doing wrong here?
....
Now: Journal entry
Invoice Name Partner
SAJ/2013/0003 / ACME Company

It is made against ACME Company, so... it's right.
---
Conclusions:
1. I can not register contact with their own addresses or contact fields, If I want, I have got to duplicate them but... what for? If I can not use them on documents?
2. With the simple, real example, I can confirm that WE DO NEED at less Partner-Address table, even if in your new aproach there is only a single partners table to register also contacts/employess. I mean...
If you define Address, with only address fields as they are street, country, Zip... an so on... you could save more than one problem easily with your datamodel aproach. It's same aproach that we have with banks. Noone can think about creating a new partner to have a new bank for a partner. Same for addresses.
3. If you allow having related:
Partner --> N address
Partner --> N partner
Address --> N partner
You have got Well built base_contact on this case but... having reused your partner single table. That would be an improvement over last versions since you don't need having duplicate fields on several tables.
On Documents you only need having links agains address, instead of partner as it was before. But... you will be reusing partner table for setting, contacts, or employees or any other conceptual object meaning also person.
It's very very easy.
Please tell me if I'm wrong and why I'm wrong.

@Olivier: Is there any place where I could test also base_contact 7.0 aproach? I would like to see if it's solving something more. Thank you!
Ana

[Fabien (Open ERP) (fp-tinyerp)]

Ana,

Thanks for taking the time to test the proposition. I put some
explanations bellow.

On 12/04/13 22:40, Ana Juaristi Olalde wrote:
> OK... Testing as asked by Fabien in Runbot.
>
> Sale order:
> Customer ACME Company Walt disney studios 444444444 Orlando, FL 33333 United States
> Invoice Address John Doe for Acme Company (ACME Company) John Doe Home Address 3838383838 Myhome, FL 2222 United States
> Delivery Address Agrolait 69 rue de Namur 1300 Wavre Belgium

I checked your record on runbot. You did two mistakes as shown in the
screenshot in attachment:
   - no need to write "John Doe for ACME" in the name as ACME is always
linked to John Doe
   - you can not write the Home address in the field address of "John
Doe, ACME". "John Doe, ACME"'s data must be the data of John Doe at
ACME: <email address hidden>, address of ACME where john doe is working, ...

> It seems quite extrange to be allowed sending goods to Agrolait when
> it's another partner, but... extremly it could be. (Bug easily can fixed
> including right domain on sale order)

Yes, this has to be discussed. This feature is required by a few
companies and was available with the base_partner_relation module in
v6.1. In a default installation, the user do not have the possibility to
set a different delivery address than the order address as you have to
check the option "Allow using a different delivery and invoicing
address". Both approaches (domain or not) are ok for me, they all have
theirs pros and cons.

> Going further:
> Picking is correctly set to Agrolait. Sales order printing is correctly printed but is showing also John Doe's home address.

Because that's what you wrongly recorded.

Note that if you do the same mistake in v6.1 (recording the Home address
on a contact of a company), you get exactly the same, wrong, behaviour.

> Next step:
> Create invoice from picking:
> Customer John Doe for Acme Company (ACME Company) John Doe Home Address 3838383838 Myhome, FL 2222 United States
> FOR ME THIS IS TOTALLY WRONG. INVOICE CONTACT is John DOE, but... INVOICE ADDRESS SHOULD BE the one from ACME
> What am I doing wrong here?

Because that's what you wrongly recorded.

Note that if you do the same mistake in v6.1 (recording the Home address
on a contact of a company), you get exactly the same behaviour.

So, according to your test, the result looks exactly the same in v6.1
and v7.

> Conclusions:
> 1. I can not register contact with their own addresses or contact fields, If I want, I have got to duplicate them but... what for? If I can not use them on documents?

By default, whether you use v6.1 or v7, contacts have only one address
associated to them. If it's a contact of a company, it has to be the
address of the company, if it's a contact not linked to a company, it
can be it's home address. If you want two addresses on a contact (a home
and a company one), you have to create two records or install the
base_contact module.

Note that in v7, we will improve the useability by changing the label
"Address" to "Company Address" to avoid this misunderstanding when
recording contacts. I did it on runbot to help you reproduce the flow.

> 2. With the simp...

[Stefan Rijnhart (Opener) (stefan-opener)]

In response to Fabien's call for support for Raphaël's solution, Therp does indeed support the idea and principles that it is built upon. In terms of implementation details, we understand that it is a proof of concept and we still think a mix-in class would be an elegant solution.

We prefer the use of a field called contact_id over inconsistently changing the semantics of partner_id. In the OpenERP 7.0 data model with or without the changes suggested by OpenERP SA, it refers to the company partner on accounting moves, but on invoices it can also refer to the contact partner. In Raphaël's solution, having partner_id referring to the company partner is not only consistent in terms of data model, it is also compatible with previous versions of OpenERP. It also prevents the need for elaborate workarounds on business documents that lack the direct link to the company partner in the OpenERP 7.0 data model.

We prefer that the system reads the relevant data directly from the partner_id field instead of that data being copied from the company to its contacts. Keeping the partner_id and its original meaning, and allowing the relevant data to be read from it directly, will prevent many regressions and data integrity problems in official and community modules.

We think that that stability, in terms of minimizing the number of bugs that integrators and users are being confronted with in using OpenERP 7.0 is more important than sticking to the 'no database changes in stable' policy of OpenERP SA.

It seems to me that a solution built on these principles does everything that OpenERP SA had in mind for OpenERP 7.0. If that is the case (maybe Fabien can comment on that), and if it is indeed the no-changes policy of OpenERP SA that drives the adoption of elaborate code that copies data around in a relational database and breaks the fundamental link between commercial entities and business document in its ERP system, then that policy is bad and has to be violated just this once or maybe even be changed to simply having a very high threshold for such changes. We would find it scary if OpenERP SA could not find a pragmatic way of dealing with this policy in times of crisis such as this one.

We would gladly contribute to implementing the adoption of these principles in the core of OpenERP 7.0 as proposed by Maxime if Fabien promises to give it a chance even if it breaks the no-changes policy. Migration scripts will be included.

[Fabien (Open ERP) (fp-tinyerp)]

Stefan,

I appreciate your willingness to contribute.

We are convinced that our solution is the best one for the OpenERP product. Our goal is to build the best product ever, even if it's against some's ideas or willingness not to change. So, we will not merge Akretion's proposal in OpenERP, but I would be happy to offer a pack of belgian beer to Akretion for their contribution to the issue. (they will get it the 3st of July)

In order to move forward, I think it's better to concentrate community's efforts on testing Olivier's branch before merging it into the stable.

All arguments have been listened and understood (from all sides) so if you want to convince us that we missed something, please provide a real scenario that show our implementation is not good.

If you are ready to contribute:
  - We need you to test the Olivier's branch to check that there are no bugs,
  - We need you to code review Olivier's branch to improve it's quality or propose enhancements,
  - We need you to adapt the documentation to the new model.

Thanks, in advance, for your contributions.

[Stefan Rijnhart (Opener) (stefan-opener)]

Fabien,

I do not feel that you are addressing my issues. It is not about whether Olivier's code implements the principles that you set out correctly, it is the principles themselves. I am sure that Olivier is capable enough of copying data around in a relational database, but it is simply bad practice to do so. I can see that it is possible to retrieve the company partner for any business document using some Python code, but not having them linked directly is pretty odd for an ERP. I can see that having a partner_id and a commercial_entity_id, provided by a separate module gives a complete set of information, but it changes the meaning of partner_id around which causes inconsistent naming in the core (compare the use of 'partner_id' on the accounting models) and incompatibility with legacy code. It also creates the need for an uncertain amount of such modules to complement other models.

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

Keeping the partner_id semantics the same as in earlier versions means less code changes means less bugs. That is currently a high priority. Our customers expect a product to mature in that sense. We cannot suggest our customers to migrate to 7.0 if it means more instability or paying to create customizations to implement core functionality that existed in an uncustomized older version.

In terms of functionality, we surely agree. Having the contact as the starting point of every business document is a good thing to have. So please consider the approach that we favour. Raphaël's idea to keep partner_id semantics in tact and add the contact_id for the user to work with is very transparent, suits your purposes fine, can be implemented elegantly and brings less instability. So please confirm if you can be pragmatic about a minor set of database changes in 7.0 and we will give you something to test.

[Ana Juaristi Olalde (ajuaristio)]

+1 to stephan.

Before going on writing about something that we consider not technical issue but conceptual issue, I would like to test 7.0-base-contact-xal just because almost all my customer are using base_contact on older versions. Maybe I will have got to recognize that I'm mistake but before that, I would like to test several use case and I see it disabled on runbot. Could someone please make it ready to connect? I'm not very used to use runbot so I have no idea if I could make it available myself.

Thank you very much:
Ana

[Stefan Rijnhart (Opener) (stefan-opener)]

Ana,

I think it's here, maybe it was just building when you looked: http://7-0-base-contact-xal-6920.runbot.openerp.com/?db=7-0-base-contact-xal-6920-all

Note that in this case, the conceptual issue has a lot of technical and usability implications.

[Ana Juaristi Olalde (ajuaristio)]

Thank you for someone making available the runbot branch so quick:

Tests made and Results with http://7-0-fix-contact-company-handling-6906.runbot.openerp.com

Test1:
Use case:
1.- Register Acme Company with main contact data in Orlando Florida
2.- Register Acme Company Invoice Dptment wich will receive usually invoices from our company
3.- Register Acme company Delivery Dptment wich will receive usually goods sent from our company

First issue found:
That's what I was trying to do but it's almost imposible just because each time I modify address field on each one of them, value is copied to all anothers, so... I can not register by now:
Acme Company, Address: walt disney studios
Acme company delivery address: walt disney studios delivery address
Acme company invoice address: walt disney studios invoice address.
So Copying data from one register to another has nosense on this case.
-----
This aproach was easily covered on 6.1 since we had got 1 partner --> N address, even without installing base_contact.

Test 2:
Register both created addresses as contact of main partner Acme Company

Usability issue: This are NOT contacts, are just addreses.
On form does not apply Job possition, nor birthdate or accounting fields. Only on real contacts they apply.

Second usability issue: Even if addresses are not set "is_company", they are shown on customers list. What for? They are NOT partners they are addresses. I don't understand that.

Test3:
Try to set John Dow as Financial manager on Acme invoice address
I can not do that, because Acme invoice address is not shown on John dow company field. So... if I set Acme Company, all contact fields for John Doe are filled with Acme company data. That's Wrong.
I only want to set John Doe as financial manager on Acmes's financial Dptment. I don't know how to do that.

Ok... I will set Acme's delivery dptment and Acme's invoice dptment as "is_company",so... I'm going to menu, look for financial deptment and set is_company to something that is not. Before of that I'm saving John Doe, just with his home address.

Opening Financial dptment... wait a minute... ALL ACME addresses are set as John Home Address...
Pufff... I think I can not going on with this solution. It can not be like that. There is no way to try to explain it to a final customer. Usability has been totally lost. Meaning of objects has been lost. Updates are made and some data are being getting lost... so..

I don't know. Is there anything more that I could try to test?
I think at this point where I'm not able to just registering master data. It has nosense that I try to make any operational workflow...

For sure this aproach is nothing to do with the older aproach we had before. Just master data could be set correctly without any problem. I could have several addresses with different types for a customer and I could set several contacts with their own data on each one of those address with contact data on their working place. I could also set people individual contact data correctly even if they were in another table... so... I'm totally lost with this new aproach where almost setting a single address with contacts it's something like a nig...

[Fabien (Open ERP) (fp-tinyerp)]

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

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

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

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

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

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

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

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

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

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

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

> I can see that it is possible to retrieve the company
> partner for any business document using some Python code, but not having
> them linked directly is pretty odd for an ERP. I can see that having a
> partner_id and a commercial_entity_id, provided by a separate module
> gives a complete set of information, but it changes the meaning of
> partner_id around which causes inconsistent naming in the core (compare
> the use of 'part...

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

>
>
> As Olivier said, the problem of raphael's branch is not that he tried to
> limit changes. The problem is that he tries to simulate the v6.1 logic on
> top of the v7 data model/semantic which as no sense.
>
> This leads to:
> - a lot of side effects as he impacts all business documents
> - a wrong usage of objects according to how they have been developed
>

I strongly disagree with this claim Fabien: during 8 years, hundreds of
people collaborated to make the model we have in 6.1 work. And that model
almost never used contacts, only marginally as an extra field. But
partner_id was NEVER a contact and this is exactly what the code has been
developed for, not only in the official addons but also in the thousands of
community modules you are so proud to quote.

On the contrary, the 7.0 developments were mostly web/usability things
(unfortunately) and that change to put addresses and partners inside the
same table (which is a good move I think) but WITHOUT anticipating almost
anything related to the semantic change of partner_id and the relational
cardinality discrepancies with contacts being in partner_id for a code that
was absolutely not planed for that. As this bug and others mentioned
regressions around contact just proves it. That is OpenERP objects were
certainly not developed for partner_id to be eventually a contact as you
claim. Only the recent v7 4-5 social eye candy features nobody here really
cares about at best.

I totally don't want to revert everything to 6.1. It's cool that you can
pick anything in the contact_id field because everything is now in the same
table. It's cool if you can send a mail or a message to a company or a
person with the same code and SQL key.
Now I say it's not because SOME code can cope both with persons and
companies that you can blindly mix them ALWAYS as if they were the same
thing. Specially in a world that is all carried by SQL which determine what
we can do or not at a reasonable effort and performance at the end of the
day.

And you say it's "Raphaël", but if you read carefully the thread, EVERYBODY
here said they want 2 keys: the partner_id key and the contact_id key.
NOBODY here stood up and said "mixing companies and contacts in partner_id
is the right thing, OpenERP SA is right". NOT A SINGLE guy except Olivier
and you defended that idea.
Sorry but you are blind if you don't see this from reading the thread.

You say my code impacts everything, but I think instead it fixes all the
issues that have been opposed to you in this thread. Oh yes, it currently
send the email to the company instead of the contact, but it's something
much less critical and easy to fix, specially easy as with my code you can
still use contact_id because you can CHOOSE if you want a contact or
partner_id which is guaranteed to be the company (or physical person) just
like the vast majority of existing code expects.

As for the code not being very clean: well of course, once things are
screwed in the core, un-crewing them without forking might be acrobatic,
that's acknowledged.
At least that code proves it's possible to fix v7 and this is what I
wanted. People can easily try the module at
https://bugs.launchpad.net...

[Alexandre Fayolle - camptocamp (alexandre-fayolle-c2c)]

For the record I personnally support Raphael's view expressed in comment #136, and I strongly believe everyone at Camptocamp share that opinion.

[Ana Juaristi Olalde (ajuaristio)]

+1 @Alexandre and @raphaël Just to support both you, even if I let just clear all around the post what I'm thinking about all this question.

Nobody is asking to revert everything to 6.1 but... coming back at less to 1 partner-n addresses should be mandatory.

Thank you:
Ana

[Maxime Chambreuil (http://www.savoirfairelinux.com) (max3903)]

+1 @rvalyi and the community.

2 fields solve all the scenarios for B2B and B2C.

1 field (contact_id) displayed to the user, named Customer and searching through companies and contacts.
1 field (partner_id) hidden by default, set automatically to the first commercial entity in the tree (at the moment contact_id is chosen) and used for invoicing.

[Fabien (Open ERP) (fp-tinyerp)]

> 2 fields solve all the scenarios for B2B and B2C.

Can you read my comment, test olivier's branch and tell us which scenario is not working with this proposition?

> 1 field (contact_id) displayed to the user, named Customer and searching through companies and contacts.
> 1 field (partner_id) hidden by default, set automatically to the first commercial entity in the tree (at the moment contact_id is chosen) and used for invoicing.

Did you notice that:
  - it requires to change all objects (if john.doe@acme fills a claim, the answer will be send to info@acme, and it's the same for all printed documents)
  - it sometimes has no sense: applicants (what's the company for an applicant?), bank statements (there are no contact on a statement), ...
  - you sometimes loose information: if you modify partner_id, it magically overwrite your contact_id (loss of data)
  - if a module already defined contact_id for another purpose, you have a conflict

Can we please stay factual, and argue with real scenario based on tests? Real examples will help the discussion become clearer. Otherwise, it looks like we are turning around without progress.

Fabien

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

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

>
>
> > 1 field (contact_id) displayed to the user, named Customer and searching
> through companies and contacts.
> > 1 field (partner_id) hidden by default, set automatically to the first
> commercial entity in the tree (at the moment contact_id is chosen) and used
> for invoicing.
>
> Did you notice that:
> - it requires to change all objects (if john.doe@acme fills a claim,
> the answer will be send to info@acme, and it's the same for all printed
> documents)
>

Fabien, OpenERP SA isn't paying me to do your job, that's us paying you. So
it's was just a quick proof of concept as I explained. Of course it would
need to be completed.
In such case, for you the code is very simple instead of what we have to do
it you swap partner_id semantic.
In these rare cases, you just have to change partner_id by contact_id in
the code. That's it.
And also it's much less critical features than say screwing your intrastat
reports or not being able to compare your supplier prices. In any case it's
way simpler to fix.

> - it sometimes has no sense: applicants (what's the company for an
> applicant?), bank statements (there are no contact on a statement), ...
>

Fabien, I agree, that some objects fields should opt-out for not receiving
a contact_id decoration. I had mentioned that in the code already.
I started elaborating a list of which fields may not be eligible for such
contact_id decoration:
Help is welcome in columns H and I:
https://docs.google.com/a/akretion.com.br/spreadsheet/ccc?key=0AlrjP6ETn3tJ<https://docs.google.com/a/akretion.com.br/spreadsheet/ccc?key=0AlrjP6ETn3tJdC1CUEw2bGQ1RkhDR0lmS2dGT1E4eWc#gid=0>

If contact_id decoration should be an opt-in or opt-out based on these
results is totally up for debate.

Also we may not add a contact_id on a field that is already restricted to a
commercial entity (while having a contact_id here wouldn't hurt either as
partner_id would be correct, it would just be useless that's it).
I explained the idea here:
https://docs.google.com/a/akretion.com.br/document/d/1CvPz-BZnZ-waQZoFpdIM6aNjjcbdLadGQqTZFL3lw7A/edit#heading=h.19sozwzfx45i

  - you sometimes loose information: if you modify partner_id, it magically
> overwrite your contact_id (loss of data)

we have two solutions here:

   1. require that you write both the contact and the partner in these
   cases (it's pretty rare code write on the partner alone once it has already
   been written, would that loose the contact in any critical manner here?
   unlikely)
   2. I think we could drop that feature once we make sure the addons
   properly write into contact_id when they should (like from a CRM lead to a
   sale order). Also, as I show contact_id even when it's empty when there is
   a partner_id, eventually that may not even be required at all. Not sure.

> - if a module already defined contact_id for another purpose, you have a
> conflict
>

Well in the very rare cases (5 cases in the whole the official addons) a
field is called contact_id and points to a res.partner, we can assume it's
really meant to carry a contact and we skip adding a contact field.

Honestly Fabien is much easier to handle than having for instance to
rewrite all our loc...

[Stefan Rijnhart (Opener) (stefan-opener)]

>> - if a module already defined contact_id for another purpose, you have a
>> conflict
>>
> Well in the very rare cases (5 cases in the whole the official addons)

For the record, I was just checking this and there are none. I believe
the five occurrences of contact_id that you spotted are just variables
that are assigned a browse record and then used as follows:

     event/event.py: contact_id = addr_obj.browse(cr, uid,
contact, context=context)
     event/event.py: 'email':contact_id.email,

[Nhomar - Vauxoo (nhomar)]

Jajajaja So funny the presentation, I just want think that OpenERP didn't
F*~k nobody ;-) (I need to see again this movie).

Some point at the end of the day, we need to give answers to everysingle
document, because the many2one nightmare is there Fabien, Ok i can live
with the new data structure, I can live with the new models stuff, but for
Sure I think it is worng in terms of think all options, and the table
shared by Raphael speak by itself.

Lets say, this was what i was talking about before, no matter the solution
we need to analize the impact in every object, because in some cases the
contact is right in other ones the contact is totally incorrect.

This remember me the problem with the invoice and the number, OpenERP
design a new solution, "We use it" and it is working in our localizations.

What will be this time friend?

Because even in some cases will not be the "End Solution" just put the
contact, even you will need to develop a configuration option, where
(Contact if or Partner if) how will we manage that?.

Regards.

2013/4/14 Stefan Rijnhart (Therp) <email address hidden>

> >> - if a module already defined contact_id for another purpose, you
> have a
> >> conflict
> >>
> > Well in the very rare cases (5 cases in the whole the official addons)
>
> For the record, I was just checking this and there are none. I believe
> the five occurrences of contact_id that you spotted are just variables
> that are assigned a browse record and then used as follows:
>
> event/event.py: contact_id = addr_obj.browse(cr, uid,
> contact, context=context)
> event/event.py: 'email':contact_id.email,
>
> --
> 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 "...

[Maxime Chambreuil (http://www.savoirfairelinux.com) (max3903)]

@ Fabien

I just updated my odony branch and here is the scenario I tested :

Create Customers with :
Camptocamp
    Joël
Akretion
    Raphaël

Create a SO for Joël, confirm it and generate the invoice.
Group invoices by partner -> CamptoCamp : 1 invoice

Go to Joël and change his company to Akretion.
Group invoice by partner -> Akretion: 1 invoice

You will tell me that this is normal to you, because your customer is Joël not C2C, right ? You want to handle B2C, but this scenario is B2B and you can't handle it with your solution.

So, now your turn, download rvalyi's branch and test this scenario, assuming that:
- if C2C is the customer, I don't change the partner_id field on the SO and the invoice will remain for C2C after Joël's transfer.
- IfJoël is the customer, you change the partner_id back to Joël on the SO and the invoice will always belong to Joël.

[Ana Juaristi Olalde (ajuaristio)]

@Fabien:
Let me say again that I'm not agree with your comments here:
  - the address to send the quote to must be the one of the contact, not the company
NO. The address to send the quote IS an address belonging to company. Not more, not less.

  - the delivery address to use depends on the contact, not on the company (If Sandro buys sth, we have to deliver in Bruxelles, not in Grand-Rosiere, even if both GR and Bruxelles are defined as valid delivery address, and sandro is just a contact)
No, SANDRO could buy something to be send to Grand Rosiere. The pales where you are sending goods is totally independent on Contact/people making the sale order and ordering WHERE (address) he want's to send goods.
Real example: Yesterday was my birthday. Someone outside my company and of course my home address sent me pink flowers. He ordered for me to a different address where they live or work. Nothing more. I'm not the flower shop's customer, my address is not part of the structure the orderer has got. I received the flowers but I did not pay any invoice. Real case where you need having registered an address to sent goods but this address doesn't belong to ordering partner. So... on this case you need 2 keys on picking (partner who is ordering, who is going to pay and address(contact) where you are sending goods)

  - the pricelist depends on the contact, not the company
I don't know any real case where you define different pricelist depending on contact. You say international sites for a company could have different prices on each country but... I don't know any company in the world that if they are placed in different countries they don't have different VAT on each of them so THEY ARE different PARTNERS no contacts.
Let's say ZARA Spain, Zara USA, or ZARA japan... I'm sure they are owning different vat numbers on each country and YES, they are part of a group so they need parent_id to be related between them in order to obtain group statistics.

  - even the fiscal position may depend on the contact, not on the company
Not in Spain. I don't know in other countries but... I don't know any case where fiscal position is depending on contact. Contact could be a contact or an address and fiscal settings and rules are ALWAYS related to partner. Otherwise it's ilegal.

About trying to configure real cases... Yesterday, I tried to test Olivier's base_contact branch. I expended a couple of hours trying to set a real basic structure. It's supposed I'm advanced user and I have not been able to do it. Just read my comment #134. I stopped just because I couldn't so... how is it suposed to work a basic final user?
-----
@maxime, thank you for your example. It's just very basic and similar to those that I tried to write here and I agree with you but I'm afraid that they are not going to recognize there is a conceptual basic problem on model so any example we can write will be not seriously considered.

@raphael: I say nothing to you!! GOOD WORK with your slides but.. I'm with Alexandre Fayolle on twitter where he says that profanity will not help the debate and better choosing words carefully.

Thank you everybody supporting this thread:
Ana

[Fabien (Open ERP) (fp-tinyerp)]

Maxime,

As you may know; users should never change the company of a contact
because the contact started to work for another company. The only valid
reason [1] to change the company of a contact is because you fix a
wrongly created record. And, for those that want to handle contacts that
change of companies, we have the base_contact module for this.

Your problem is not related at all with the current discussion. It just
points out a usability issue which is that a user may change the company
of a contact for an invalid reason. Olivier proposed to put a warning to
avoid this mistake for end-users. We don't want to put the field
readonly as you sometimes have to change the company of an existing
contact for a valid reason [1].

Anyway, your scenario gives wrong expectations in v6.1, v7 and Raphaël's
branch.

In v6.1, after modification of Joël from Camptocamp to Akretion, the
invoice has the following fields:
     . Partner: Camptocamp
     . Invoice Address: Joël, Akretion
     . Contact Address: Joël, Akretion
         --> inconsistencies

In Raphael's branch, the invoice has the following fields:
   - Partner: Camptocamp
   - Invoice Address: Joël, Akretion
         --> inconsistencies [2]

In v7:
   - Partner: Joël, Akretion
   - Partner Company: Akretion
         --> consistent, but probably not what the user expect

In these 3 versions, the invoice is sent to Akretion's address. (side
note: In v6.1, as an opposite to the two others, it's sent to Akretion
but with the title 'Camptocamp'.)

As a conclusion;
   - it's normal to have wrong expectations, if you record wrong data.
But, if the change is for a valid reason [1], only v7 is consistent and
correct after the change.
   - v7's data model ensure consistency in the data: it's not possible
to have an invoice for a company whereas the address belongs to another
company
   - Raphaël's branch is totally inconsistent: on the screen you see
"Joël, Akretion", but when you print it, you see "Camptocamp"

[1] Two examples of a valid reason to change the company of the contact;
1/ I record Joël by mistake for the AMCE company and I fix this to ACME
later 2/ I have two customers "Camptocamp" and "Camptocamp SAS" in my DB
and I want to merge these two customers. If you change the company for a
valid reason, v7 does the expect behaviour, not v6.1, not Raphaels branch.

[2] The reason why you probably did not noticed that Raphaël's branch
data are wrong is that it has another bug: printed invoices are always
sent at the company address, not at the invoice address, even if you
define an invoice address. Same for emails, it uses the generic company
email. (try to send an invoice to <email address hidden>, you will probably
never be paid as our leads are forwarded to partners :) So, on the
screen you see "Joël, Akretion", but when you print it, you see
"Camptocamp".

So, in my opinion, your example, even if it's not a valid scenario,
plays largely in favor of v7.

Fabien

On 14/04/13 14:33, Maxime Chambreuil (http://www.savoirfairelinux.com)
wrote:
> @ Fabien
>
> I just updated my odony branch and here is the scenario I tested :
>
> Create Customers with :
> Camptocamp
> ...

[Fabien (Open ERP) (fp-tinyerp)]

On 14/04/13 16:26, Ana Juaristi Olalde wrote:
> @Fabien:
> Let me say again that I'm not agree with your comments here:
> - the address to send the quote to must be the one of the contact, not the company
> NO. The address to send the quote IS an address belonging to company. Not more, not less.

Yes, it's the same. The address of the contact is the same than the one
of the company (at least the postal address, the email address not).
It's just that one company may have several offices, so you have to use
the right one (the one where the contact is working).

> - the delivery address to use depends on the contact, not on the company (If Sandro buys sth, we have to deliver in Bruxelles, not in Grand-Rosiere, even if both GR and Bruxelles are defined as valid delivery address, and sandro is just a contact)
> No, SANDRO could buy something to be send to Grand Rosiere. The pales where you are sending goods is totally independent on Contact/people making the sale order and ordering WHERE (address) he want's to send goods.

Yes, OpenERP just does proposition in the sale order. The user can
change and put whatever address he wants. The proposition algorythm will
use the address which is set as a default for the delivery. If there are
no default, it will use the office of Sandro by default (but you can
change and deliver to another office if you want).

> Real example: Yesterday was my birthday. Someone outside my company and of course my home address sent me pink flowers. He ordered for me to a different address where they live or work. Nothing more. I'm not the flower shop's customer, my address is not part of the structure the orderer has got. I received the flowers but I did not pay any invoice. Real case where you need having registered an address to sent goods but this address doesn't belong to ordering partner. So... on this case you need 2 keys on picking (partner who is ordering, who is going to pay and address(contact) where you are sending goods)

Happy birthday, even if I am one day late.

> - the pricelist depends on the contact, not the company
> I don't know any real case where you define different pricelist depending on contact. You say international sites for a company could have different prices on each country but... I don't know any company in the world that if they are placed in different countries they don't have different VAT on each of them so THEY ARE different PARTNERS no contacts.
> Let's say ZARA Spain, Zara USA, or ZARA japan... I'm sure they are owning different vat numbers on each country and YES, they are part of a group so they need parent_id to be related between them in order to obtain group statistics.

Usually it's not, the pricelist is the same for the whole company by
default in OpenERP. But, we can imagine the other scenario in B2B,
working for big companies. It's not a matter of country but department.
Some companie, like Caterpillar in Belgium, are so big that you can
apply different strategies according to the department you sell to.

I am not telling it's the default use case. The default use case is to
have the same pricelist for the whole company. I am just telling that
it's possibl...

[Ana Juaristi Olalde (ajuaristio)]

@Fabien:
Thank you for whising me happy birthday!! Flowers were really nice.

Now, coming back to the problem... imaging simply for a moment that a customer 6.X having installed and usign 6.X base_contacts and having OPW tells you that ... OK but I don't want my data to fit that new structure on 7.0. I wan't to mantain my structure since I think it's correct. i don't want you to touch that structure because I don't think really is good and you can not convince me it's better than the one I have got now.

Would it be possible in a really small percentaje of possibilities that OpenERP could have something that "older versions compatibility" module, that we could use with that kind of customers in 7.0?

That is... Would it be possible to think about a simply aproach like it is 7.0 now and complex aproach as we had on past(even if it's still possible improving it) making difference on installing and configuring an extra module?

I think it shouldn't be so difficult creating just that module where everybody would be happy. People liking your aproach will be happy and people don't liking it OR customers don't wanting their data being re-designed would be happy. Do you think this could be possible in a short future?

Thank you:
Ana

[Michael Telahun Makonnen (mmakonnen)]

+1 for partner_id + contact_id

@ fabien said in reply #146:
" As you may know; users should never change the company of a contact
because the contact started to work for another company. The only valid
reason [1] to change the company of a contact is because you fix a
wrongly created record. And, for those that want to handle contacts that
change of companies, we have the base_contact module for this.

Your problem is not related at all with the current discussion. It just
points out a usability issue which is that a user may change the company
of a contact for an invalid reason. "

You can't have it both ways. Either the contact is a "first-class" object or it isn't. If it is a first-class object then it should represent a real world person. When a company changes address you change the company's address. You don't create a second company with a different address. If John Doe changes company you should change John Doe's address to the new company and OpenERP should still behave correctly. It's disingenuous of you to blame the inconsistencies in your data model on the user.

Having said that...

No one disagrees that a contact should be a first-class object in the database model. I like it and pretty much everybody else also seems to like it. The problem we have with that is when you take that and apply it to the business model (I am making a distinction between the data model and the business model). In the business model a contact is not a first-class object. The first-class object is always the entity you have a business relationship with (ie. the company). The contacts are incidental to this relationship and they can change, disappear, whatever without affecting the relationship whatsoever. So when you send an invoice you can send it to the contact, but the recipient should be the company, not the contact. Notice, I didn't say it should be addressed to the company. It's a subtle, but very important distinction.

From your addition of a 'commercial_id' field to res.partner it seems like you also acknowledge that there is at least *a* distinction...

... Which leads to the next problem we have: So, if you acknowledge the need for a 'commercial_id' why do you have to "silently" change the semantics of a very important field implicitly acknowledged by your pre-7.0 data *and* business model as the "commercial_id" but misspelled as partner_id? Keep the misspelling and put the contact in its own field called contact_id. By your own acknowledgement the contact was a rarely used feature in previous versions. So I have to believe that from the point of view of creating the least disruption this is the simplest solution that is the closest to the business model.

Lastly, you've stated that one of the reasons for not going the partner_id + contact_id route is that it would change the 7.0 database schema. This is a moot point. There would have been no need to change the schema had all this been discussed with your community before hand. The fact that we are contemplating changing the schema now, after 7.0, is as a result of OpenERP SA not having thought out the implications of its changes completely before releasing 7.0 to the world and s...

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

@Folks,

Sorry, my link to decide if a m2o key can be a contact or not and if we should add a contact_id field was wrong, here is it:

https://docs.google.com/document/d/1CvPz-BZnZ-waQZoFpdIM6aNjjcbdLadGQqTZFL3lw7A/edit?usp=sharing
Thank you for helping filling the exhaustive spreadsheet as we have to do it.

@Fabien

You keep answering as if the question was to merge my POC monkeypatch. It's not! it just a POC!
In the cases you are telling, all we need is change the code to replace "partner_id" by "contact_id", so yes, even in a few reports.
In any case, real OpenERP integrations impacted by this bug rarely even use these native OpenERP reports sadly...

Also is a relatively easy change for things that are much less critical than what I describe here if we use only one key mixing companies and persons or swap the partner_id semantic:
https://docs.google.com/presentation/d/1y0njSpm9kqJPGFUQQTiRMIpT1M5CfKppNhslvpl-aM4/pub?start=false&loop=false&delayms=3000#slide=id.p
In these cases, the bugs are critical because the are not about using the company instead of a contact, they use contacts instead of the companies and really fixing them everywhere is very very complex as I explain.

Thanks.

[Nicolas JEUDY (njeudy)]

hello all,

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

What I'm sure:

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

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

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

TRACEBACK

Integrity Error

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

[object with reference: Invoice - account.invoice]

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

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

But:

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

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

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

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

@fabien, @odony:

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

It is an extreamly important bug, lots of modules, working instances and business logics are based on this. Next time, write a road map, discuss and vote to validate choice that are so important ? We (partner, community) want to do a great job with our customers and with openERP but, for the moment we only k...

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Now, the remarks of Fabien about reports where we need to change partner_id by contact_id in reports tend to make me think we will never achieve it as a monkey patch like at did in the POC at #27 because even if changing partner_id by contact_id in a few place is simple, we can probably not achieve it in just a few modules without being too invasive (eg overriding whole report which is too brutal).

So real solution will be between:
1) a merge
2) a branch
3) a fork

I will try to recode my proposal in a branch instead. In any case, that would be cool if people help to fill
https://docs.google.com/document/d/1CvPz-BZnZ-waQZoFpdIM6aNjjcbdLadGQqTZFL3lw7A/edit?usp=sharing
So that we can properly add contact_id fields or not only when we should.

Again, my view is all that sounds terribly sad. Well, but sorry I fail to believe I can do the kind of implementations I did in 6.1 without a proper solution to that.

Regards.

[Nicolas JEUDY (njeudy)]

@rvalyi:

- Your spreadsheet is a good analyse, and I think when partner can be a contact, we just show contact_id field on view and calculate partner_id according to it (we can use commercial_entity function .. ) else, we show partner_id and contact_id or only contact_if if option is not to enable partner_id modification ?

What do you think ?

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

@Nicolas,

when the field can be a contact, it's because it already has an other pointer to the partner like partner_invoice_id in sale.order. Or, it's because it doesn't matter at all in the existing codebase to have a company here: for instance the work address of an employee.

So I think in practice, we don't need to do anything: don't had a contact_id field and don't do anything in the view in these cases.

Do you agree?

[Nicolas JEUDY (njeudy)]

Yes it.'s ok for me

Le dimanche 14 avril 2013, Raphaël Valyi - http://www.akretion.com <
<email address hidden>> a écrit :

> @Nicolas,
>
> when the field can be a contact, it's because it already has an other
> pointer to the partner like partner_invoice_id in sale.order. Or, it's
> because it doesn't matter at all in the existing codebase to have a
> company here: for instance the work address of an employee.
>
> So I think in practice, we don't need to do anything: don't had a
> contact_id field and don't do anything in the view in these cases.
>
> Do you agree?
>

--
Nicolas JEUDY

Expert Technique et Fonctionnel Système d'Information
TUXSERVICES

22 rue du seminaire - 25170 Pelousey
e-mail : <email address hidden>
mob. : [phone]
http://www.tuxservices.com

[Fabien (Open ERP) (fp-tinyerp)]

On 14/04/13 20:20, Michael Telahun Makonnen wrote:
> +1 for partner_id + contact_id

Why not partner_id + commercial_id ? This would be the solution to
satisfy everyone's need.

> @ fabien said in reply #146:
> " As you may know; users should never change the company of a contact
> because the contact started to work for another company. The only valid
> reason [1] to change the company of a contact is because you fix a
> wrongly created record. And, for those that want to handle contacts that
> change of companies, we have the base_contact module for this.
>
> Your problem is not related at all with the current discussion. It just
> points out a usability issue which is that a user may change the company
> of a contact for an invalid reason. "
>
> You can't have it both ways. Either the contact is a "first-class"
> object or it isn't.

"John Doe, Acme" is a first-class object, not "John Doe". If you want to
manage "John Doe" as a person, you need base_contact module (it's not
related to our solution, it's the same in v6.1 and in raphael's
proposition too).

> If it is a first-class object then it should
> represent a real world person. When a company changes address you change
> the company's address. You don't create a second company with a
> different address. If John Doe changes company you should change John
> Doe's address to the new company and OpenERP should still behave
> correctly. It's disingenuous of you to blame the inconsistencies in
> your data model on the user.

As I said, it's not related to our solution, it's the same in v6.1 and
raphael's proposition too.

> No one disagrees that a contact should be a first-class object in the
> database model. I like it and pretty much everybody else also seems to
> like it. The problem we have with that is when you take that and apply
> it to the business model (I am making a distinction between the data
> model and the business model). In the business model a contact is not a
> first-class object. The first-class object is always the entity you have
> a business relationship with (ie. the company). The contacts are
> incidental to this relationship and they can change, disappear, whatever
> without affecting the relationship whatsoever.

The person "John Doe" can die. But, in the database, the entity "John
Doe, Acme" can not disappear. Because, in the real life, this
information does not disappear: your contracts are signed "John Doe, for
ACME", you can not remove the signature "John Doe" and keep only "for
ACME" on all contracts. That's why contacts can not be deleted but they
can be set as not active anymore.

> So when you send an
> invoice you can send it to the contact, but the recipient should be the
> company, not the contact. Notice, I didn't say it should be addressed to
> the company. It's a subtle, but very important distinction.

Yes, we do agree with that.

That's what we do in our implementation:
   - address: partner_id.street (the contact)
   - receivable: partner_id.commercial_id.account_receivable.id (the
company)

With partner_id.account_receivable.id ==
partner_id.commercial_id.account_receivable.id.
Because partner_id is "John Doe, Acme", not "John...

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

On Sun, Apr 14, 2013 at 5:37 PM, Fabien (Open ERP) <email address hidden> wrote:

> On 14/04/13 20:20, Michael Telahun Makonnen wrote:
> > +1 for partner_id + contact_id
>
> Why not partner_id + commercial_id ? This would be the solution to
> satisfy everyone's need

Because of course it would forces us to change all the code everywhere
where partner_id is used: that is what we call "swapping" the semantic.
This is a lot of very risky work we cannot afford doing for v7.
Instead of the added field is contact_id. Everywhere code that comes from
v6.1 (the vast majority of the code that matters), we can still use
partner_id normally.
The question only becomes where exactly do we add these contact_id fields
and how exactly do we add them (in the ORM automatically, in every class
but then we need collaboration from OpenERP SA and less also ensure we
avoid code duplication like when patching the views) and also where exactly
are the few places with contact_id should be used instead of partner_id in
reports or to send a mail.

Regards.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

That is "partner_id + commercial_id" we would need to face all the
issues described here except 1) may be
https://docs.google.com/presentation/d/1y0njSpm9kqJPGFUQQTiRMIpT1M5CfKppNhslvpl-aM4/pub?start=false&loop=false&delayms=3000#slide=id.p

and if you read that thread well, people actually want "partner_id +
contact_id", just for these reasons.

On Sun, Apr 14, 2013 at 6:03 PM, Raphael Valyi <email address hidden> wrote:

> On Sun, Apr 14, 2013 at 5:37 PM, Fabien (Open ERP) <email address hidden> wrote:
>
>> On 14/04/13 20:20, Michael Telahun Makonnen wrote:
>> > +1 for partner_id + contact_id
>>
>> Why not partner_id + commercial_id ? This would be the solution to
>> satisfy everyone's need
>
>
> Because of course it would forces us to change all the code everywhere
> where partner_id is used: that is what we call "swapping" the semantic.
> This is a lot of very risky work we cannot afford doing for v7.
> Instead of the added field is contact_id. Everywhere code that comes from
> v6.1 (the vast majority of the code that matters), we can still use
> partner_id normally.
> The question only becomes where exactly do we add these contact_id fields
> and how exactly do we add them (in the ORM automatically, in every class
> but then we need collaboration from OpenERP SA and less also ensure we
> avoid code duplication like when patching the views) and also where exactly
> are the few places with contact_id should be used instead of partner_id in
> reports or to send a mail.
>
> Regards.
>

[Maxime Chambreuil (http://www.savoirfairelinux.com) (max3903)]

@fabien

We all agree we need 2 levels, but disagree on field names:
* The community wants contact and partner
* OpenERP SA wants partner and commercial_entity

If we were having this discussion a year ago I would say : "Let's go with your data model with the same field names : contact vs partner" and OpenERP SA would have implemented it during 2012.

Unfortunately, we never had this discussion last year, you chose to use one field partner_id and forgot about the second level. You realized the problem 3 months after the release and now you want to add the second level with commercial_entity_id.

You are just trying to push your solution into our throat, because you already did the migration of your modules to the new field names. You leave us with no other way than migrating our modules AND updating them to your field names. You made a mistake and the community has to assume it. This is not fair and unprofessional.

Where does this lead us ?
1) OpenERP SA merges Olivier's branch and the community adapts his modules to use partner vs commercial entity.
2) OpenERP SA assumes his responsibility, reverts its modules to use contact vs partner, releases a 7.1 and handles the migration from 7.0 to 7.1.

Fabien, can you provide a third option where each party will at least get out of this situation with something ? Otherwise the frustration will go on forever.

Can you also make sure the Community is involved earlier in the process to avoid this situation in the future ? I hope we will use this situation as a way to grow and move forward.

Thank you very much for your answer (comment #146).

[Fabien (Open ERP) (fp-tinyerp)]

On 15/04/13 03:04, Maxime Chambreuil (http://www.savoirfairelinux.com)
wrote:
> @fabien
>
> We all agree we need 2 levels, but disagree on field names:
> * The community wants contact and partner
> * OpenERP SA wants partner and commercial_entity

I think we disagree on the principle, not on the field names. We want
partner_id, commercial_id because:
   - partner_id is the main field (commercial_id is just a readonly
function field to guarantee consistency)
   - commercial_id is not required on all objects as it's exactly the
same than partner_id.commercial_id, so we will just put it where it's
required as a technical artifact to allow specific reporting, not
everywhere.

> If we were having this discussion a year ago I would say : "Let's go
> with your data model with the same field names : contact vs partner" and
> OpenERP SA would have implemented it during 2012.
>
> Unfortunately, we never had this discussion last year, you chose to use
> one field partner_id and forgot about the second level. You realized the
> problem 3 months after the release and now you want to add the second
> level with commercial_entity_id.

As I said, we don't want to add a second level everywhere as it's just
redundancy. But we are ready to create modules for every object the
community would like to change because it's compatible with our point of
view.

> You are just trying to push your solution into our throat, because you
> already did the migration of your modules to the new field names. You
> leave us with no other way than migrating our modules AND updating them
> to your field names. You made a mistake and the community has to assume
> it. This is not fair and unprofessional.

It's not community against OpenERP SA. Whatever the solution we choose,
the community have to adapt their modules to v7 for plenty of others
reasons (res.partner.address does not exists, new form views, ...)
Renaming contact_id into partner_id is just 10 minutes of work per module.

The reason we think we should keep our model is because it's implemented
in trunk for one year and we did extensive tests and adapted all modules
for it. Trying to change this would have the opposite impact of what you
try to do: create much more bugs.

> Where does this lead us ?
> 1) OpenERP SA merges Olivier's branch and the community adapts his modules to use partner vs commercial entity.
> 2) OpenERP SA assumes his responsibility, reverts its modules to use contact vs partner, releases a 7.1 and handles the migration from 7.0 to 7.1.

1. the community adapt his modules
2. the community adapt his modules + we change all official modules (one
year) + review migrations

And they are no real argument that makes us fell our data model is
wrong. I only hear one valid argument for now on: "desactivating a contact".

> Fabien, can you provide a third option where each party will at least
> get out of this situation with something ? Otherwise the frustration
> will go on forever.

I'll try to make a proposition later today.

> Can you also make sure the Community is involved earlier in the process
> to avoid this situation in the future ? I hope we will use this
> situation as a way to gr...

[Mario Arias (the-clone-master)]

Fabien / Oliver

Could you please explain:

  * How are you copying data/attributes from companies to contacts?
  * How is this being encapsulated/hidden from addons?
  * How is this better than a relation from contact to company?

Regards,
-Mario

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Hello Fabien, inline answers:

On Mon, Apr 15, 2013 at 2:46 AM, Fabien (Open ERP) <email address hidden> wrote:

> On 15/04/13 03:04, Maxime Chambreuil (http://www.savoirfairelinux.com)
> wrote:
> > @fabien
> >
> > We all agree we need 2 levels, but disagree on field names:
> > * The community wants contact and partner
> > * OpenERP SA wants partner and commercial_entity
>
> I think we disagree on the principle, not on the field names. We want
> partner_id, commercial_id because:
> - partner_id is the main field (commercial_id is just a readonly
> function field to guarantee consistency)
> - commercial_id is not required on all objects as it's exactly the
> same than partner_id.commercial_id, so we will just put it where it's
> required as a technical artifact to allow specific reporting, not
> everywhere.
>

Fabien
if you follow the discussion, we propose adding contact_id selectively, not
everywhere, only where it makes sense, please read
https://docs.google.com/a/akretion.com.br/document/d/1CvPz-BZnZ-waQZoFpdIM6aNjjcbdLadGQqTZFL3lw7A/edit#heading=h.mdjw907uuzcb
and
https://docs.google.com/spreadsheet/ccc?key=0AlrjP6ETn3tJdC1CUEw2bGQ1RkhDR0lmS2dGT1E4eWc#gid=0

So it's not really different in term avoiding redundance.
The big difference is that "partner_id + commercial_entity_id" is a
semantic swap of the last 8 years of development and forces to review the
logic of all official and community module, while our "partner_id +
contact_id" proposal keeps the semantic untouched, that is much less bugs
are to expect.

[...]
> It's not community against OpenERP SA. Whatever the solution we choose,
> the community have to adapt their modules to v7 for plenty of others
> reasons (res.partner.address does not exists, new form views, ...)
>

The other adaptations were much simpler: the view migration is trivial. As
for the address migration: as modules tend to use companies much more than
contacts, contacts wasn't such a big deal to migrate. In any case that was
mostly about simply using the same table now. Not so much logic change.

> Renaming contact_id into partner_id is just 10 minutes of work per module.
>

NO NO AND NO
Are you kidding or lying?

If we adopt "partner_id + contact_id" then yes, indeed, it's just changing
the name to use contact_id at the few place where you really want a contact.

On the contrary, if we adopt "partner_id + commercial_entity_id", we should
review all the relational logic everywhere as I explained here:
https://docs.google.com/presentation/d/1y0njSpm9kqJPGFUQQTiRMIpT1M5CfKppNhslvpl-aM4/pub?start=false&loop=false&delayms=3000#slide=id.p

>
> The reason we think we should keep our model is because it's implemented
> in trunk for one year and we did extensive tests and adapted all modules
> for it. Trying to change this would have the opposite impact of what you
> try to do: create much more bugs.
>

I think you are kidding Fabien
Come on, you didn't test anything of the issues I presented in the slides!
you came to think about the issue of reading data from contact (and copying
them) 3 months after you said release was ready (this bug)
you only fixed the financial accounting moves on the surface 2 months after
the r...

[Nhomar - Vauxoo (nhomar)]

Fabien.

About this

||||||||||||||||||||||||||||
   - commercial_id is not required on all objects as it's exactly the
same than partner_id.commercial_id, so we will just put it where it's
required as a technical artifact to allow specific reporting, not
everywhere.
||||||||||||||||||||||||||||

It can not be a function, this is a real problem,

In V6.1 what you are calling inconcistency, we are calling loss
functionality, and for sure it is not a base_contact task (this is for
other purpose i think)
I think here we have a misunderstood, with this or i forgot something.

I can have (in real cases in 7 countries I used this feature)

Case 1: "Subsidiaries"
================

1 Partner -- > Several Invoice Addresses: This is called "Subsidiaries" and
it is not a "Functional Field", we "With business approach" had __
automated some assignations __ but basically it is NOT at all a function
field and less "Read Only".

Ah and BTW: We use this a a "Fiscal Requirement " in México, in VE 1
partner >> 1 Invoice address (This is why we didn't see it before)

In this case the Address is "Just" A contact.

Extra Information:

We developed in the past some constraints for Venezuela because we can not
have 2 invoices Addresses for one partner, with V7 we __just__ remove the
constraint to other object.

Results:
======

Pro: Oliver solution works Model Works, because you lock what was not
locked.

Cons: But it is Incomplete in terms of what we had in V6.1, more freedom
and inconsistencies, but easily customizable by constraints We did several
Times and we dont have problem to migrate our approach but with the same
base data model --at least in terms of number of fields--).

Sol: ????

Accounting PoV:
============

In this case all accounting information was taken from the partner itself,
in this point, what we got with new version is the same, (Oliver Approach).

From Reports:
===========

All was consolidated to the same partner, I don't know if it is in this way
yet, i couldn't find the way with Oliver approach.
In this Point is important, and very important, that you consider, in the
past the report was:

SELECT * FROM object WHERE conditions GROUP BY partner_id;

What ever you decide different to this, is a regression in terms of
performance, we __must__ to solve this IMHO.

FYI we have a big deal (H**) Fabrice can support me on that with something
like 15k Invoices PER DAY, imagine the problem with an approach in reports
with python code ;-)

I think it can be solved easily, I am sure you will offer a good approach
(or a workaround considering our PoV)

Case 2 : "Consortium"
======

1 Partner > Several Partners Childs_Of with Total Different "Fiscal
Information" this is called "Consortium"

In V6.1 we had the field parent_id (not used in any place in the core) that
allow us build this feature with taking as pivot you old model.

Then, we simple fill a Partner with is own Fiscal information, and in any
time, i can move freely as part of any "Consortium".

It was used by us to consolidate too! every partner had his own Fiscal and
legal Information separatelly, but i could in any time (with just one
method of 10 lines) even allow the parent Partner pay ...

[Nhomar - Vauxoo (nhomar)]

The email before was too long

About the same:

=============
   - commercial_id is not required on all objects as it's exactly the
same than partner_id.commercial_id, so we will just put it where it's
required as a technical artifact to allow specific reporting, not
everywhere.
=============

Case 3: Mix of Case 1 and 1:

We can have case 1 and 2 in my last comment mixed. (You are migrating now
one db with this approach A***)

A "consortium" of companies with several childs that have "Subsidiaries"
and with sevaral "Locations".

IT is so much complex, we mix all our modules and we are improving all the
interaction between the to solve this (It is a WiP) but I am aware that
with all the restrictions an python code involved in Odony Solution without
touch the db, it will become in a real mess.

But BTW, I am open to hear solutions?

Thanks

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

> On 15/04/13 03:04, Maxime Chambreuil (http://www.savoirfairelinux.com)
> wrote:
> > @fabien
> >
> > We all agree we need 2 levels, but disagree on field names:
> > * The community wants contact and partner
> > * OpenERP SA wants partner and commercial_entity
>
> I think we disagree on the principle, not on the field names. We want
> partner_id, commercial_id because:
> - partner_id is the main field (commercial_id is just a readonly
> function field to guarantee consistency)
> - commercial_id is not required on all objects as it's exactly the
> same than partner_id.commercial_id, so we will just put it where it's
> required as a technical artifact to allow specific reporting, not
> everywhere.
>
>
> > If we were having this discussion a year ago I would say : "Let's go
> > with your data model with the same field names : contact vs partner" and
> > OpenERP SA would have implemented it during 2012.
> >
> > Unfortunately, we never had this discussion last year, you chose to use
> > one field partner_id and forgot about the second level. You realized the
> > problem 3 months after the release and now you want to add the second
> > level with commercial_entity_id.
>
> As I said, we don't want to add a second level everywhere as it's just
> redundancy. But we are ready to create modules for every object the
> community would like to change because it's compatible with our point of
> view.
>
> > You are just trying to push your solution into our throat, because you
> > already did the migration of your modules to the new field names. You
> > leave us with no other way than migrating our modules AND updating them
> > to your field names. You made a mistake and the community has to assume
> > it. This is not fair and unprofessional.
>
> It's not community against OpenERP SA. Whatever the solution we choose,
> the community have to adapt their modules to v7 for plenty of others
> reasons (res.partner.address does not exists, new form views, ...)
> Renaming contact_id into partner_id is just 10 minutes of work per module.
>
> The reason we think we should keep our model is because it's implemented
> in trunk for one year and we did extensive tests and adapted all modules
> for it. Trying to change this would have the opposite impact of what you
> try to do: crea...

[Fabien (Open ERP) (fp-tinyerp)]

Nhomar,

> Case 1: "Subsidiaries"
> ================
>
> 1 Partner -- > Several Invoice Addresses: This is called "Subsidiaries" and
> it is not a "Functional Field", we "With business approach" had __
> automated some assignations __ but basically it is NOT at all a function
> field and less "Read Only".

Not sure you understand.

I agree that some documents may need several companies for different
purposes. As an example, in a sale order, you have different addresses
for different usage:
  - Order Contact
  - Invoice Address
  - Delivery Address

That's 3 different roles, these roles can be for different companies.
This is perfectly handled in our solution.

And this could be the same for several documents. As an example, a lot
of software add the 'delivery address' on the invoice. So, we could
create a module to handle this by adding one field.

We just say that, in our solution, we just need 3 fields for sale order
or one field for invoice (or 2 if you want to add more roles, like
delivery address)

In Raphaël's proposition, he proposes to put 6 fields on the sale order
as you need both the company and the address for every role defined in
the document. (unless you create a constraint where order contact,
delivery address and invoice address all belongs to the same company, in
this case, he only need 4 fields)

So, our solution is clean when you have different roles on the same
document (like a contact, an invoicing address and a delivery address on
the sale order).

> All was consolidated to the same partner, I don't know if it is in this way
> yet, i couldn't find the way with Oliver approach.

Please try Olivier's approach.

>
> Case 2 : "Consortium"
> ======
>
> 1 Partner > Several Partners Childs_Of with Total Different "Fiscal
> Information" this is called "Consortium"
>
> In V6.1 we had the field parent_id (not used in any place in the core) that
> allow us build this feature with taking as pivot you old model.
>
> Then, we simple fill a Partner with is own Fiscal information, and in any
> time, i can move freely as part of any "Consortium".

v7 better handle consortium as you can now consolidate more efficiently
when searching.

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

[Fabien (Open ERP) (fp-tinyerp)]

Hello,

We tested v6.1, v7-odo and Raphaël's based on all scenario that you have
reported. We put all scenario here:
  - http://bit.ly/10WPN5S

Send us the scenario you want to add in the file or tell us if you think
something is wrong (but please avoid claiming untested facts).

This spreadsheet allows to balance pros and cons of all the solutions
(v6.1, v7, raphael) to avoid being in a situation where everyone looks
for Cons in the other solutions.

There are two slides: business & technicals.

We answered all points of Rapahael's slides in this document. When it's
an answer to Raphael's slides we wrote (Slide X) on the right. Most of
them are in the technical slide.

We think that, if our solution fits all business needs, it's a good
solution. For now, on, in order to move forward, it's important to
concentrate our discussions on facts (real use cases) rather than
principles or unvalidated claims.

So, please have a look at:
   http://bit.ly/10WPN5S

Test, and tell us what's missing or wrong.

Thanks,

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

[Maxime Chambreuil (http://www.savoirfairelinux.com) (max3903)]

@fabien

If the commercial_entity_id is readonly, how do you differentiate on the sale order a personal order from Joël (invoiced to his home address) and a professional one (invoiced to C2C) ?

[Olivier Dony (Odoo) (odo-openerp)]

On 04/15/2013 02:07 PM, Maxime Chambreuil (http://www.savoirfairelinux.com) wrote:
> If the commercial_entity_id is readonly, how do you differentiate on the
> sale order a personal order from Joël (invoiced to his home address) and
> a professional one (invoiced to C2C) ?

This is a key concept to understand. If you sell something to Joël as a private
person *and* as a professional contact of C2C you need *two different
customers*. Just like you would have needed 2 different ones in 6.1.

When you use "Joël (Camptocamp)" as Customer you are referring to the
Commercial Entity "Camptocamp" via its representative "Joël (Camptocamp)".

If you also sell to Joël as a private person you are doing both B2B and B2C
sales in parallel, so you need 2 different customers records, just like in the
real world.

In v6.1 you would have needed 4 records to model this: 2 partners + 2
addresses/contacts. In v7 you only need 3: 1 business customer + his company,
and 1 stand-alone customer.

[Fabien (Open ERP) (fp-tinyerp)]

On 04/15/2013 02:07 PM, Maxime Chambreuil
(http://www.savoirfairelinux.com) wrote:
> @fabien
>
> If the commercial_entity_id is readonly, how do you differentiate on the
> sale order a personal order from Joël (invoiced to his home address) and
> a professional one (invoiced to C2C) ?
>

Like in v6.1, that's two different records. (and it's the same in
raphael's proposition too)

If you install base_contact, it's different, but I propose to put that
in antoher thread to not confuse people.

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

[Daniel Reis (dreis-pt)]

It seems to me that the central issue is the "change in granularity level".
There are a lot of qualified people discussing the what, where & how, but it seems that the WHY is yet to be explained.

Why "contact" is to be "the right level of granularity"?
========================================================

WHY the change?
What's OpenERP's reasoning behind this?

I've been trying to read their mind, and I decided to contribute to the discussion because I think I've figured it out.
For me the key was in Fabien's comment #120 (https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/120).

V7 is about Social:
From a legal POV, your company interacts with other Companies.
From a social POV, your users interact with other Company's people.

For OpenERP to be social, it needs to interact with a Contact@Partner instead of a "pure" Partner.
This way it can send emails to Contact@Partner, instead of Partner's generic e-mail,
or let Contact@Partner interact using a personal Portal user account, instead of a Partner generic one.

Thus the need for the "change in granularity".

Everyone is assuming that a Contact it's a Person working for a Company
But it's not - it's more like a Job/Position at a Company.
It's a "Contact@Partner": a Contact *at a* Partner; a Partner plus a point of contact info.
It's actually just a face, an alias, for the Partner.

But it breaks the commercial entity reference on documents?
Not in the simple, flat, partner structure you get out-of-the box on v7:
On the flat structure Partner 1->N Contacts, you just need to use `partner_id.parent_id`
where you used `partner_id` and there you are: you get exactly the same info as before.
This can also be easily achieved in SQL with just as additional join.

Explained like this, it looks like, despite being a big change, there seems to be no big deal,
and that you can do everything you could do before with pretty much the same effort.

And if the your ContactX@Customer1 person goes to work at Customer2, you don't edit Contact1:
You inactivate ContactX@Customer1 and create ContactX@Customer2!
Because "ContactX" does not make sense on itself on the new model.
It only makes sense to have "ContactX@Customer1" and "ContactX@Customer2".
And if the ContactX personally is also your Customer, then you need to also create "HomeAddress@PersonX".

Do I sound like Fabien and Olivier right now? I hope I do.

Problems came when you were able to mix "Contacts at Partners" and "Pure Partners"
on the same field, and that a lot of v7 localization ports to v7 was done assuming that
partner_id is still a company ... and when you need to add a hierarchy to the Partner table ...
But that's the already discussion going on .

I hope I contributed to a better discussion.
I'm not swimming in VC funding over here to offer a case, but I promise to bring a couple of Port wine bottles
to the OpenERP days if a solution good enough for everyone is achieved.

PS: Raphael's code was just a proof of concept for a solution.
Everyone, including Raphael, prefers a solution from OpenERP SA implemented directly in the core.
OpenERP SA should be thankful to have such an involved community, with people as skilled a...

[Mario Arias (the-clone-master)]

Fabien / Oliver

Again, could you please explain how are you handling encapsulation of your "denormalized" contacts proposal ??

  * How are you copying data/attributes from companies to contacts?
  * How is this being encapsulated/hidden from addons?
  * How is this better than a relation from contact to company?
  * How should we proceed if we need to add any aditional field from company to contact?

Regards,
-Mario

[Olivier Dony (Odoo) (odo-openerp)]

On 04/15/2013 04:09 PM, Mario Arias wrote:
> Again, could you please explain how are you handling encapsulation of
> your "denormalized" contacts proposal ??

The bulk of the idea is in the description of this bug ("Proposed solution")
and the actual implementation can be reviewed on the framework merge proposal:
https://code.launchpad.net/~openerp-dev/openobject-server/7.0-fix-contact-company-handling/+merge/157577

> * How are you copying data/attributes from companies to contacts?

This is part B of the described solution.

Since business contact and companies live in the same database table, they both
have all accounting attributes at SQL level. In the UI we forbid editing the
accounting attributes on business contacts and replace the fields with a link
to edit these attributes on the parent company.

On the database side, in order to avoid keeping empty (or worse: incorrect)
values in the accounting fields of business contacts, we implement automated
inheritance of the values (similarly to what fields.related would do). Whenever
these accounting attributes are modified on the company, the values are
automatically synchronized to the children. Same thing if the "contact-company"
link changes.

> * How is this being encapsulated/hidden from addons?

This logic is completely implemented by the res.partner model in the framework.
Addons can extend the list of fields that are considered "accounting
atttributes" and therefore automatically synchronized by overriding the
res.partner._commercial_fields() method.

The merge proposal for addons does this for the accounting attributes of all
official addons, if you want to get an idea:
https://code.launchpad.net/~openerp-dev/openobject-addons/7.0-fix-contact-company-handling/+merge/157576

> * How is this better than a relation from contact to company?

It's not better, it comes *in addition* to the contact-company relationship as
an extra security. Addons that do care about the contact vs company distinction
can directly access the correct value on the company.
But if some fail to do it properly they will still get the right value, be it
payment term, payable account, etc.

> * How should we proceed if we need to add any aditional field from company to contact?

If your module adds an accounting-related field 'special_invoice_data_id' to
res.partner, just override the method as follows and synchronization will be
done automatically:

def _commercial_fields(self, cr, uid, context=None):
   return super(res_partner, self)._commercial_fields(cr, uid, context=context)\
       + ['special_invoice_data_id']

If your field is normally editable in the "Accounting" tab of the Partner form
you have nothing else to do: it will be replaced by a link to the company form
when viewing a contact of a company. If not, have a look at the examples in the
addons merge proposal, a simple `attrs` attribute will do the job, and you can
easily add a link to open the company form if you want.

[Nicolas JEUDY (njeudy)]

@Fabien:

1) googledoc line 13: I'm not sure that on pdf this is the contact that is show as address:

- ACME FR (is company)
- ACME EUROP (is company
- JOHN DO AT ACME EUROP contact for invoicing address

When you print invoice for ACME FR, and send it for validation to JOHN DO AT ACME EUROP that is in charge of all invoice for ACME CORP, I think address should be ACME FR on invoice.

Does you mean that in this case I have to add JOHN DO AT ACME FR with same adresse , phone and email as JOHN DO AT ACME EUROP and use it to invoice ? Do you mean that this invoice will have JOHN DO ADRESS ? For me invoice has ACME FR adresse and is send by post or by email to JOHN DO AT ACME EUROP. That what we did in our customer install ... in report invoice (pdf) we have the invoice with address of ACME FR and the document is just send to JOHN DO AT ACME (just a spécial domain on invoice for contact_id) .. But the invoice IS for ACME FR.

If I'm clear with what you said I have to create a JOHN DO at ACME FR, with 1) fr address of acme ? 2) or address of JOHN DO ? (for mail, phone and fax it's JOHN do think. If 1) JOHN DO will never receive invoice for validation by post .. So i think it's WRONG. Where i'm wrong ?

2) scenario 4: How do you create this structure ? (runbot 7.0-fix-contact-company-handling is disable .. will test when it 's ok, but for me you can not add contact to partner that's not a company ...)

3) Scenario 6: I don't see case when you disable (active = false) an contact because he has left le company and you have to create a refund. For me it's not john do at ACME that should be linked to the refund and eventually new invoice but the new contact .. ?

4) Scenario 7: You have to choose if it'a john do at ACME or not ... you say all over comment that it's not john do as partner_id but john do at ACME, and base contact add ability to have more function ? (I can test now because of nginx bad gateway on runbot, but will do it) Is there a branch with base_contact and fix-contact-company to test ?

5) Scenatio 8: One company order, but the delivery is another company and invoicing too ... hum, how do you manage contact with this ?JOHN do at ACME can be contact for delivery and invoice (the person who check, validate et follow the project) and address can be different ? how do you configure this to your point of view ?

Ex: Nicolas JEUDY is in charge of a project that will be invoiced to TUXSERVICES FRANCE, and deliver to OPENERP (delivery address). But Nicolas JEUDY will be the only contact that is in charge of verifying computers are ok in OPENERP, and all goods are OK, but the delivery adresse (postal one in this case) is OPENERP ? should I create Nicolas JEUDY AT OPENERP ? Nicolas JEUDY will be able to recieve info only by email because postal adresse is wrong ...

A contact is not necessary a person who has same postal adress as company. it's just the contact for the project, invoice ... And think that the mistake ... I'm ready to test these scenario but can you just tell me how I can create this situation ?

Some questions:

- In my modules how do i know when partner_id is a contact or a company ? I have to check if parent_id exist or ...

[Nicolas JEUDY (njeudy)]

scenario 4:

- Like I said if ACME BRUXELLE OFFICE is not a company you could not add contact to it.
- WHY ACME BRUXELLE OFFICE can't be a company ?

[Nicolas JEUDY (njeudy)]

@odony @fabien:

As i said previously, can not select analytic account for my support contract on your branch .. and I think there is a lot of case like this .. contact is not partner. You want I add a support contract for all contact that can call me in a company ?

I will try all possibility to find a solution and put here all my question. I think it will be a good doc for integrator when all case will be green ...

I use very simple case with allday practice, and just small need lots of customers have without having to pay a partner to adapt all small functionalities that a editor should offer.

I read carrefully this thread and will spend a lot of time to help for finding a solution.

How can I have acces to add some scenario (like contract, timesheet, invoice) in fabien document?

[Fabien (Open ERP) (fp-tinyerp)]

Nicolas,

My answer inline.

> 1) googledoc line 13: I'm not sure that on pdf this is the contact that
> is show as address:
>
> - ACME FR (is company)
> - ACME EUROP (is company
> - JOHN DO AT ACME EUROP contact for invoicing address
>
> When you print invoice for ACME FR, and send it for validation to JOHN
> DO AT ACME EUROP that is in charge of all invoice for ACME CORP, I think
> address should be ACME FR on invoice.

It depends on the configuration. Note that your example is different
from the line 13.

Based on your example, the answer is "like in v6.1":

  - If you invoice ACME FR, the invoice is sent to ACME FR
  - If you invoice "John Doe, Acme Europe", invoice is sent to John Doe
    and accounted for ACME Europe
  - If you invoice Acme Europe, invoice is sent to ACME Europe and
    accounted for ACME Europe
  - If John Doe works for both ACME FR and ACME Europe, you have to create
    two John Doe. (because their email, phone, work address may not be
    the same)

So, it's exactly like in v6.1. (and raphael's branch follow the same too)

> 2) scenario 4: How do you create this structure ? (runbot 7.0-fix-
> contact-company-handling is disable .. will test when it 's ok, but for
> me you can not add contact to partner that's not a company ...)

Yes, it's provided by this module. The data model and the code already
allows this (we just have to make the tab active on the form). To be
fair, I also marked that this feature would have been merged in
Raphaël's branch too.

> 3) Scenario 6: I don't see case when you disable (active = false) an
> contact because he has left le company and you have to create a refund.
> For me it's not john do at ACME that should be linked to the refund and
> eventually new invoice but the new contact .. ?

I have added this scenario.

Both approaches are good: (they are pros and cons for both)
  - v6.1 & v7: invoice address of a refund is the same than the invoice
  - raphael: invoice address of a refund is recomputed as the new
    invoice address

v6.1 & v7 is better if invoice address did not changed (the address may
have changed, but not "which record" give the best address)
raphael's solution is better if it changed, but not if the address did
not changed between the invoice and refund.

> 4) Scenario 7: You have to choose if it'a john do at ACME or not ... you
> say all over comment that it's not john do as partner_id but john do at
> ACME, and base contact add ability to have more function ? (I can test
> now because of nginx bad gateway on runbot, but will do it) Is there a
> branch with base_contact and fix-contact-company to test ?

Not yet. You must merge both locally.

Note that base_contact should not have impact according to the solution.
It's behaviour should be the same.

> 5) Scenatio 8: One company order, but the delivery is another company
> and invoicing too ... hum, how do you manage contact with this ?JOHN do
> at ACME can be contact for delivery and invoice (the person who check,
> validate et follow the project) and address can be different ? how do
> you configure this to your point of view ?

Two solutions:
  - you do it manually on the order: as OpenERP does only propositio...

[Fabien (Open ERP) (fp-tinyerp)]

On 04/15/2013 06:31 PM, Nicolas JEUDY wrote:
> scenario 4:
>
> - Like I said if ACME BRUXELLE OFFICE is not a company you could not add contact to it.

Why?
The most common scenario is one company having several offices (like
OpenERP SA has two offices, one in bruxelles and one in grand-rosière)
and there are different people working in each office.

> - WHY ACME BRUXELLE OFFICE can't be a company ?

Yes, we can do that too, but it's a different scenario. It's subsidiaries.

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

[Fabien (Open ERP) (fp-tinyerp)]

Daniel,

Here is a presentation about the "Why" we did that change:
  http://bit.ly/17eMp8F

If not about social aspects.
It's because it better reflects the real life.

On 04/15/2013 03:54 PM, Daniel Reis (SECURITAS SA) wrote:
> It seems to me that the central issue is the "change in granularity level".
> There are a lot of qualified people discussing the what, where & how, but it seems that the WHY is yet to be explained.
>
> Why "contact" is to be "the right level of granularity"?
> ========================================================
>
> WHY the change?
> What's OpenERP's reasoning behind this?
>
> I've been trying to read their mind, and I decided to contribute to the discussion because I think I've figured it out.
> For me the key was in Fabien's comment #120 (https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/120).
>
> V7 is about Social:
>>From a legal POV, your company interacts with other Companies.
>>From a social POV, your users interact with other Company's people.
>
> For OpenERP to be social, it needs to interact with a Contact@Partner instead of a "pure" Partner.
> This way it can send emails to Contact@Partner, instead of Partner's generic e-mail,
> or let Contact@Partner interact using a personal Portal user account, instead of a Partner generic one.
>
> Thus the need for the "change in granularity".
>
> Everyone is assuming that a Contact it's a Person working for a Company
> But it's not - it's more like a Job/Position at a Company.
> It's a "Contact@Partner": a Contact *at a* Partner; a Partner plus a point of contact info.
> It's actually just a face, an alias, for the Partner.
>
> But it breaks the commercial entity reference on documents?
> Not in the simple, flat, partner structure you get out-of-the box on v7:
> On the flat structure Partner 1->N Contacts, you just need to use `partner_id.parent_id`
> where you used `partner_id` and there you are: you get exactly the same info as before.
> This can also be easily achieved in SQL with just as additional join.
>
> Explained like this, it looks like, despite being a big change, there seems to be no big deal,
> and that you can do everything you could do before with pretty much the same effort.
>
> And if the your ContactX@Customer1 person goes to work at Customer2, you don't edit Contact1:
> You inactivate ContactX@Customer1 and create ContactX@Customer2!
> Because "ContactX" does not make sense on itself on the new model.
> It only makes sense to have "ContactX@Customer1" and "ContactX@Customer2".
> And if the ContactX personally is also your Customer, then you need to also create "HomeAddress@PersonX".
>
> Do I sound like Fabien and Olivier right now? I hope I do.
>
> Problems came when you were able to mix "Contacts at Partners" and "Pure Partners"
> on the same field, and that a lot of v7 localization ports to v7 was done assuming that
> partner_id is still a company ... and when you need to add a hierarchy to the Partner table ...
> But that's the already discussion going on .
>
> I hope I contributed to a better discussion.
> I'm not swimming in VC funding over here to offer a case, but I promise to bring a couple of Port wine bo...

[Nhomar - Vauxoo (nhomar)]

Hello Fabien.

In testing process.

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

> Daniel,
>
> Here is a presentation about the "Why" we did that change:
> http://bit.ly/17eMp8F
>
>
Can you share the source to translate it please?.

Thanks.

> If not about social aspects.
> It's because it better reflects the real life.
>
>
> On 04/15/2013 03:54 PM, Daniel Reis (SECURITAS SA) wrote:
> > It seems to me that the central issue is the "change in granularity
> level".
> > There are a lot of qualified people discussing the what, where & how,
> but it seems that the WHY is yet to be explained.
> >
> > Why "contact" is to be "the right level of granularity"?
> > ========================================================
> >
> > WHY the change?
> > What's OpenERP's reasoning behind this?
> >
> > I've been trying to read their mind, and I decided to contribute to the
> discussion because I think I've figured it out.
> > For me the key was in Fabien's comment #120 (
> https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/120).
> >
> > V7 is about Social:
> >>From a legal POV, your company interacts with other Companies.
> >>From a social POV, your users interact with other Company's people.
> >
> > For OpenERP to be social, it needs to interact with a Contact@Partnerinstead of a "pure" Partner.
> > This way it can send emails to Contact@Partner, instead of Partner's
> generic e-mail,
> > or let Contact@Partner interact using a personal Portal user account,
> instead of a Partner generic one.
> >
> > Thus the need for the "change in granularity".
> >
> > Everyone is assuming that a Contact it's a Person working for a Company
> > But it's not - it's more like a Job/Position at a Company.
> > It's a "Contact@Partner": a Contact *at a* Partner; a Partner plus a
> point of contact info.
> > It's actually just a face, an alias, for the Partner.
> >
> > But it breaks the commercial entity reference on documents?
> > Not in the simple, flat, partner structure you get out-of-the box on v7:
> > On the flat structure Partner 1->N Contacts, you just need to use
> `partner_id.parent_id`
> > where you used `partner_id` and there you are: you get exactly the same
> info as before.
> > This can also be easily achieved in SQL with just as additional join.
> >
> > Explained like this, it looks like, despite being a big change, there
> seems to be no big deal,
> > and that you can do everything you could do before with pretty much the
> same effort.
> >
> > And if the your ContactX@Customer1 person goes to work at Customer2,
> you don't edit Contact1:
> > You inactivate ContactX@Customer1 and create ContactX@Customer2!
> > Because "ContactX" does not make sense on itself on the new model.
> > It only makes sense to have "ContactX@Customer1" and "ContactX@Customer2
> ".
> > And if the ContactX personally is also your Customer, then you need to
> also create "HomeAddress@PersonX".
> >
> > Do I sound like Fabien and Olivier right now? I hope I do.
> >
> > Problems came when you were able to mix "Contacts at Partners" and "Pure
> Partners"
> > on the same field, and that a lot of v7 localization ports to v7 was
> done assuming that
> > partner_id is still ...

[Fabien (Open ERP) (fp-tinyerp)]

Nhomar,

>> Here is a presentation about the "Why" we did that change:
>> http://bit.ly/17eMp8F
> Can you share the source to translate it please?.
>

Olivier will improve tomorrow and send you a version you can translate.

Fabien

[Mario Arias (the-clone-master)]

Thanks Olivier for your time,

I still don't like this "denormalized" record. As you said, information
is all there, but that attribute copying makes me really nervous.... all
the floating point and dates based on UTC nightmares we all are still
suffering come to my mind right away....

Besides, that extra "sanity check" that you are imposing to migrate
modules from 6.1 to 7.0 is by no means "small".

Now, best way to test it is with real life module migrations, so we will
start working on a couple upgrades from 6.1 to 7.0, and will report back
when done...

As to echo others, having companies and contacts in one table is not the
problem, but the lack of complete information about the change and too
optimistic testing, and mainly... not acknowledging at first that there
was a BIG problem with the original release, and instead attacking the
ones raising the flag...

You really are in debt with Raphaël....

Please stop repeating that "we have tested it for the last year" song,
as that makes us wonder what kind of testing you did that missed these
problems in the model. Instead, be humble and accept you screwed up...
same as WE ALL failed to catch this sooner too...

Regards,
-Mario

On 04/15/2013 08:42 AM, Olivier Dony (OpenERP) wrote:
> On 04/15/2013 04:09 PM, Mario Arias wrote:
>> Again, could you please explain how are you handling encapsulation of
>> your "denormalized" contacts proposal ??
> The bulk of the idea is in the description of this bug ("Proposed solution")
> and the actual implementation can be reviewed on the framework merge proposal:
> https://code.launchpad.net/~openerp-dev/openobject-server/7.0-fix-contact-company-handling/+merge/157577
>
>
>> * How are you copying data/attributes from companies to contacts?
> This is part B of the described solution.
>
> Since business contact and companies live in the same database table, they both
> have all accounting attributes at SQL level. In the UI we forbid editing the
> accounting attributes on business contacts and replace the fields with a link
> to edit these attributes on the parent company.
>
> On the database side, in order to avoid keeping empty (or worse: incorrect)
> values in the accounting fields of business contacts, we implement automated
> inheritance of the values (similarly to what fields.related would do). Whenever
> these accounting attributes are modified on the company, the values are
> automatically synchronized to the children. Same thing if the "contact-company"
> link changes.
>
>
>> * How is this being encapsulated/hidden from addons?
> This logic is completely implemented by the res.partner model in the framework.
> Addons can extend the list of fields that are considered "accounting
> atttributes" and therefore automatically synchronized by overriding the
> res.partner._commercial_fields() method.
>
> The merge proposal for addons does this for the accounting attributes of all
> official addons, if you want to get an idea:
> https://code.launchpad.net/~openerp-dev/openobject-addons/7.0-fix-contact-company-handling/+merge/157576
>
>
>> * How is this better than a relation from contact to company?
> It's not better, it come...

[Fabien (Open ERP) (fp-tinyerp)]

Nicolas,

On 15/04/13 20:57, Fabien (Open ERP) wrote:
>> Some questions:
>> >
>> > - In my modules how do i know when partner_id is a contact or a company
>> > ? I have to check if parent_id exist or if commercial_id existe ? what
>> > is the way you think we should do it ?
> * is_company is checked if it's a company
>
> Please note that*you never need this*. Some data should belong to the
> company (account receivable, fiscal position) other data should come
> from the company (address, phone, email).
>
> If you need:
> - an account receivable: partner_id.commercial_id.account_receivable
> - an email: partner_id.email
>
> This always works for all kind of contacts and hierarchies:
> - subsidiaries of groups
> - single persons
> - main company
> - person representing a company
> - departments
>
> When you implement a module, if you think the pricelist should come from
> the company, you do this partner_id.commercial_id.pricelist or, if you
> think the pricelist belong to the contact, you do this:
> partner_id.pricelist.
>

I am sorry, but I may have created more confusion here. Everything
that's written above is correct, but it's even simpler than that.

You can *always do partner_id.the_field_i_need* and it works; no matter
if it's a company, a person, a representative of a company... The v7
model ensure that every record holds the right data. (e.g. "John Doe,
Acme" has the pricelist of Acme).

So, in your own module, you don't need to worry at all about
commercial_id. That's why community module should work nearly as it.

Fabien

[Nicolas JEUDY (njeudy)]

@fabien

Ok I read all your comment, I will try real example and try to add video of what I mean.

I just want to add and explain two scenario:

1) scenario 10: What about invoice to walt Disney but send it to john do that as to validate it because he is in charge of want should be done and has role to verify that the invoice is correct ? You have this with company and international office for example. The man "accounting manager" of ACME is the contact of all invoice for FR office, BELGIUM Office, but invoice is linked to fr office, BELGIUM office .. I may be wrong but I have two customer that do this actually and I don't know how to setup this in v7. With rapahel branch I just have to set contact to "accounting manager" and partner to fr Office for example. But yes we have to link openchatter, email and commication to contact_id instead of partner id. Like you said rename partner_id by contact in module take 10min ;)

2) Invoice issue and task on timesheet.

- Create a contract (annual support contract) with company ACME. You define that support cost 60 EUR / hours.
- Check task and issue on this contract and invoice on timesheet.

Now a man (or woman !) call me because he/she has a problem. I create an issue assigned to me, and contact Miss Anna who want to have adresse on openerp in different tables. I work on it and record my work time. As I can have more than one open project with ACME, and as OpenERP set it to mandatory, I need to record my time on a project/analytique account. But as my previous screenshot show, you have no analytic account in many2one widget because they are filtered on contact, and contact has no project on it, this is ACME that has this ..

So how to deal with this ? With Raphael solution (and 6.1 one) you have partner and contact on issue. Even if partner is invisible, analytic account can be filtered with it and not on contact. Contact is just the person you talk with, and the person that will receive email, ticket, and so, but ACME is the business logic target of all invoice, contract, project ... (it's the same with task.)

I think contact_id is the right granularity for end user guy (person that use openerp and record some data), but company (partner_id) is the right granularity for business document. If you want to have what you code in V7 juste set partner_id to invisible and add the onchange function to set the correct partner_id. no data duplication, no problem. The only data replication you have is when contact and partner are the same, but it will be "rare" enough, because in real world you speak with contact (person, department, etc ..) about business object of a company he belongs to.

I really like the simplicity of what as be done, but to be honest, we are losing consistancy and stability just because you choose to connect / fusion contact and partner and think I not so simple ...

I think the problem is more complexe than you mean. How many scenario to you want to see it. I know you take lots of time for this issue (me too :) ) and I wish we would find a good solution for our customer and our customer data.

In 15 min I will post video on the second scenario . it would be more simple to understa...

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Guys, I see lot's of talking about details,
but sometimes a sometimes a picture is worth a thousand words.
The following diagram summarizes the change in version 7, just for the
invoice object for instance:

goo.gl/utTMU

Sometimes the big pictures really helps.

On Mon, Apr 15, 2013 at 6:25 PM, Nicolas JEUDY <email address hidden>wrote:

> @fabien
>
> Ok I read all your comment, I will try real example and try to add video
> of what I mean.
>
> I just want to add and explain two scenario:
>
> 1) scenario 10: What about invoice to walt Disney but send it to john do
> that as to validate it because he is in charge of want should be done
> and has role to verify that the invoice is correct ? You have this with
> company and international office for example. The man "accounting
> manager" of ACME is the contact of all invoice for FR office, BELGIUM
> Office, but invoice is linked to fr office, BELGIUM office .. I may be
> wrong but I have two customer that do this actually and I don't know how
> to setup this in v7. With rapahel branch I just have to set contact to
> "accounting manager" and partner to fr Office for example. But yes we
> have to link openchatter, email and commication to contact_id instead of
> partner id. Like you said rename partner_id by contact in module take
> 10min ;)
>
> 2) Invoice issue and task on timesheet.
>
> - Create a contract (annual support contract) with company ACME. You
> define that support cost 60 EUR / hours.
> - Check task and issue on this contract and invoice on timesheet.
>
> Now a man (or woman !) call me because he/she has a problem. I create an
> issue assigned to me, and contact Miss Anna who want to have adresse on
> openerp in different tables. I work on it and record my work time. As I
> can have more than one open project with ACME, and as OpenERP set it to
> mandatory, I need to record my time on a project/analytique account. But
> as my previous screenshot show, you have no analytic account in many2one
> widget because they are filtered on contact, and contact has no project
> on it, this is ACME that has this ..
>
> So how to deal with this ? With Raphael solution (and 6.1 one) you have
> partner and contact on issue. Even if partner is invisible, analytic
> account can be filtered with it and not on contact. Contact is just the
> person you talk with, and the person that will receive email, ticket,
> and so, but ACME is the business logic target of all invoice, contract,
> project ... (it's the same with task.)
>
>
> I think contact_id is the right granularity for end user guy (person that
> use openerp and record some data), but company (partner_id) is the right
> granularity for business document. If you want to have what you code in V7
> juste set partner_id to invisible and add the onchange function to set the
> correct partner_id. no data duplication, no problem. The only data
> replication you have is when contact and partner are the same, but it will
> be "rare" enough, because in real world you speak with contact (person,
> department, etc ..) about business object of a company he belongs to.
>
> I really like the simplicity of what as be done, but to be honest, we
> are losing...

[Nicolas JEUDY (njeudy)]

Video playist for last comment:

#fabien: case 2 in my post seems to work now .. but many2one widget seems not to know the analytic account you forced. but it works .

http://www.youtube.com/playlist?list=PLDo85hjMzeJN2atAdrxsYH5rHxGdc8apo

[Nicolas JEUDY (njeudy)]

@rvalyi: I think it is very strange to rename contact_id to partner_id and partner_id to commercial_entity_id. Now it's time to find a solution and see how to close this issue. I will try all scenario with V7 and Odony branch, and try to propose scenario if I see one that can be a problem.

I don't know if duplicate data is good or not, even if I would prefer not duplicating it, but ... Let try all scenario and see ...

[Nicolas JEUDY (njeudy)]

Purchase test:

Try to add a contact to purchase order for agrolait ... no contact are in list:

-> http://www.youtube.com/watch?v=B9Xui4ddN3Y&list=PLDo85hjMzeJN2atAdrxsYH5rHxGdc8apo&index=2

Try to search Tang at asustek in supplier .. no tang, I find it in customer !:

-> http://www.youtube.com/watch?v=E9ZeUO1rdQc&list=PLDo85hjMzeJN2atAdrxsYH5rHxGdc8apo&index=3

really 12 month of testing ? :) change tester ...

[Nicolas JEUDY (njeudy)]

One more video:

group task by partner_id :

-> http://www.youtube.com/watch?v=ABcvCnEYhBI&list=PLDo85hjMzeJN2atAdrxsYH5rHxGdc8apo&index=4

really great data model ...

[Fabien (Open ERP) (fp-tinyerp)]

>
> 1) scenario 10: What about invoice to walt Disney but send it to john do
> that as to validate it because he is in charge of want should be done
> and has role to verify that the invoice is correct ? You have this with
> company and international office for example. The man "accounting
> manager" of ACME is the contact of all invoice for FR office, BELGIUM
> Office, but invoice is linked to fr office, BELGIUM office .. I may be
> wrong but I have two customer that do this actually and I don't know how
> to setup this in v7. With rapahel branch I just have to set contact to
> "accounting manager" and partner to fr Office for example. But yes we
> have to link openchatter, email and commication to contact_id instead of
> partner id. Like you said rename partner_id by contact in module take
> 10min ;)

Like in v6.1: you create several accounting manager, one for each company. (or you install base_contact) Please note that it does not work for raphael branch too.

Side note: Your use case is very strange, I don't think I ever saw an accounting soft that do that. (I never saw an accounting software that prints two addresses on an invoice, one for the real company, another one for the company that should receive it. When there are a second address on invoices, it's for delivery address)

> 2) Invoice issue and task on timesheet.
>
> - Create a contract (annual support contract) with company ACME. You define that support cost 60 EUR / hours.
> - Check task and issue on this contract and invoice on timesheet.
>
> Now a man (or woman !) call me because he/she has a problem. I create an
> issue assigned to me, and contact Miss Anna who want to have adresse on
> openerp in different tables. I work on it and record my work time. As I
> can have more than one open project with ACME, and as OpenERP set it to
> mandatory, I need to record my time on a project/analytique account. But
> as my previous screenshot show, you have no analytic account in many2one
> widget because they are filtered on contact, and contact has no project
> on it, this is ACME that has this.

It's a bug. (the first we found that requires to change addons/business documents)
Should be fixed by Olivier.
We should grep "domain.*partner_id.*=.*partner_id" in the code.

> I think contact_id is the right granularity for end user guy (person that use openerp and record some data), but company (partner_id) is the right granularity for business document. If you want to have what you code in V7 juste set partner_id to invisible and add the onchange function to set the correct partner_id. no data duplication, no problem. The only data replication you have is when contact and partner are the same, but it will be "rare" enough, because in real world you speak with contact (person, department, etc ..) about business object of a company he belongs to.

We are convinced that the current solution is the right one.

We may find a few bugs because all objects/views have been changed in v7, but not that much. (note that this one is the very first we found on addons related to the partner issue, all others have been fixed on the partner object)

>
> I really like the simplicity of what as be ...

[Nicolas JEUDY (njeudy)]

Contract test:

Group contract by parnter:

-> http://www.youtube.com/watch?v=DDZWQxFI3xE&list=PLDo85hjMzeJN2atAdrxsYH5rHxGdc8apo&index=5

How can I manage contract and contact on contract ? who will receive contract document ? where can I encode this ? Sorry but you need two fields, or can you say how I can manage this ?

[Fabien (Open ERP) (fp-tinyerp)]

It's because Asustek is marked as a supplier, but not it's contact Tang.
Looks like it's normal to me:
  - you can not buy at Tang (a contact from the manufacturing dept)
  - but you can buy at Marc (a salesman)
We could improve demo data to mark some contacts as "suppliers"

Note also that the propagation of context changed recently in the web client. Olivier was working on it today. So, the creation of a supplier may not create contacts as "supplier." Be sure the contact as the checkbox set "Is a supplier"

> Purchase test:
>
> Try to add a contact to purchase order for agrolait ... no contact are
> in list:
>
> ->
> http://www.youtube.com/watch?v=B9Xui4ddN3Y&list=PLDo85hjMzeJN2atAdrxsYH5rHxGdc8apo&index=2
>
> Try to search Tang at asustek in supplier .. no tang, I find it in
> customer !:
>
> ->
> http://www.youtube.com/watch?v=E9ZeUO1rdQc&list=PLDo85hjMzeJN2atAdrxsYH5rHxGdc8apo&index=3
>
> really 12 month of testing ? :) change tester ...
>
> --
> 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
>
> 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 o...

[Cristian Salamea (ovnicraft)]

On Mon, Apr 15, 2013 at 6:15 PM, Fabien (Open ERP) <email address hidden> wrote:

> >
> > 1) scenario 10: What about invoice to walt Disney but send it to john do
> > that as to validate it because he is in charge of want should be done
> > and has role to verify that the invoice is correct ? You have this with
> > company and international office for example. The man "accounting
> > manager" of ACME is the contact of all invoice for FR office, BELGIUM
> > Office, but invoice is linked to fr office, BELGIUM office .. I may be
> > wrong but I have two customer that do this actually and I don't know how
> > to setup this in v7. With rapahel branch I just have to set contact to
> > "accounting manager" and partner to fr Office for example. But yes we
> > have to link openchatter, email and commication to contact_id instead of
> > partner id. Like you said rename partner_id by contact in module take
> > 10min ;)
>
> Like in v6.1: you create several accounting manager, one for each
> company. (or you install base_contact) Please note that it does not work
> for raphael branch too.
>
> Side note: Your use case is very strange, I don't think I ever saw an
> accounting soft that do that. (I never saw an accounting software that
> prints two addresses on an invoice, one for the real company, another
> one for the company that should receive it. When there are a second
> address on invoices, it's for delivery address)
>
>
> > 2) Invoice issue and task on timesheet.
> >
> > - Create a contract (annual support contract) with company ACME. You
> define that support cost 60 EUR / hours.
> > - Check task and issue on this contract and invoice on timesheet.
> >
> > Now a man (or woman !) call me because he/she has a problem. I create an
> > issue assigned to me, and contact Miss Anna who want to have adresse on
> > openerp in different tables. I work on it and record my work time. As I
> > can have more than one open project with ACME, and as OpenERP set it to
> > mandatory, I need to record my time on a project/analytique account. But
> > as my previous screenshot show, you have no analytic account in many2one
> > widget because they are filtered on contact, and contact has no project
> > on it, this is ACME that has this.
>
> It's a bug. (the first we found that requires to change addons/business
> documents)
> Should be fixed by Olivier.
> We should grep "domain.*partner_id.*=.*partner_id" in the code.
>

Just to clarifiy @Fabien, documents has partner_id (as contact) and linked
to company ACME, where i get fiscal data ? partner ? company ?

Regards,

>
> > I think contact_id is the right granularity for end user guy (person
> that use openerp and record some data), but company (partner_id) is the
> right granularity for business document. If you want to have what you
> code in V7 juste set partner_id to invisible and add the onchange
> function to set the correct partner_id. no data duplication, no problem.
> The only data replication you have is when contact and partner are the
> same, but it will be "rare" enough, because in real world you speak
> with contact (person, department, etc ..) about business object of a
> company he belongs to.
>
> We are convi...

[Nhomar - Vauxoo (nhomar)]

@cristian.

28 + def _commercial_id_compute(self, cr, uid, ids, name, args,
context=None):

Here:

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

Answer you the question, I am testing yet with some more deep PoC but I
think it is bringing good approach, I am fear yet in other models, as Raph
says but in invoices it is shown like it is working pretty well.

2013/4/15 Cristian Salamea (Gnuthink) <email address hidden>

> On Mon, Apr 15, 2013 at 6:15 PM, Fabien (Open ERP) <email address hidden>
> wrote:
>
> > >
> > > 1) scenario 10: What about invoice to walt Disney but send it to john
> do
> > > that as to validate it because he is in charge of want should be done
> > > and has role to verify that the invoice is correct ? You have this with
> > > company and international office for example. The man "accounting
> > > manager" of ACME is the contact of all invoice for FR office, BELGIUM
> > > Office, but invoice is linked to fr office, BELGIUM office .. I may be
> > > wrong but I have two customer that do this actually and I don't know
> how
> > > to setup this in v7. With rapahel branch I just have to set contact to
> > > "accounting manager" and partner to fr Office for example. But yes we
> > > have to link openchatter, email and commication to contact_id instead
> of
> > > partner id. Like you said rename partner_id by contact in module take
> > > 10min ;)
> >
> > Like in v6.1: you create several accounting manager, one for each
> > company. (or you install base_contact) Please note that it does not work
> > for raphael branch too.
> >
> > Side note: Your use case is very strange, I don't think I ever saw an
> > accounting soft that do that. (I never saw an accounting software that
> > prints two addresses on an invoice, one for the real company, another
> > one for the company that should receive it. When there are a second
> > address on invoices, it's for delivery address)
> >
> >
> > > 2) Invoice issue and task on timesheet.
> > >
> > > - Create a contract (annual support contract) with company ACME. You
> > define that support cost 60 EUR / hours.
> > > - Check task and issue on this contract and invoice on timesheet.
> > >
> > > Now a man (or woman !) call me because he/she has a problem. I create
> an
> > > issue assigned to me, and contact Miss Anna who want to have adresse on
> > > openerp in different tables. I work on it and record my work time. As I
> > > can have more than one open project with ACME, and as OpenERP set it to
> > > mandatory, I need to record my time on a project/analytique account.
> But
> > > as my previous screenshot show, you have no analytic account in
> many2one
> > > widget because they are filtered on contact, and contact has no project
> > > on it, this is ACME that has this.
> >
> > It's a bug. (the first we found that requires to change addons/business
> > documents)
> > Should be fixed by Olivier.
> > We should grep "domain.*partner_id.*=.*partner_id" in the code.
> >
>
> Just to clarifiy @Fabien, documents has partner_id (as contact) and linked
> to company ACME, where i get fiscal data ? partner ? company ?
>
> Regards,
>
> >
> > > I think c...

[Cristian Salamea (ovnicraft)]

On Mon, Apr 15, 2013 at 8:16 PM, Nhomar - Vauxoo <email address hidden> wrote:

> @cristian.
>
> 28 + def _commercial_id_compute(self, cr, uid, ids, name, args,
> context=None):
>
> Here:
>
> https://code.launchpad.net/~openerp-dev/openobject-server/7.0-fix-
> contact-company-handling/+merge/157577
>
> Answer you the question, I am testing yet with some more deep PoC but I
> think it is bringing good approach, I am fear yet in other models, as Raph
> says but in invoices it is shown like it is working pretty well.
>

function field for commercial entity great ! and it is choose by a while
loop fantastic !

I dont see any constraint for is_company and parent_id what happen if has
+1 partner is_company true ?

i really want to read an example to extend that methods and models.

 Just remember this: "If the implementation is hard to explain, it's a bad
idea."

Regards,

>
>
>
> 2013/4/15 Cristian Salamea (Gnuthink) <email address hidden>
>
> > On Mon, Apr 15, 2013 at 6:15 PM, Fabien (Open ERP) <email address hidden>
> > wrote:
> >
> > > >
> > > > 1) scenario 10: What about invoice to walt Disney but send it to john
> > do
> > > > that as to validate it because he is in charge of want should be done
> > > > and has role to verify that the invoice is correct ? You have this
> with
> > > > company and international office for example. The man "accounting
> > > > manager" of ACME is the contact of all invoice for FR office, BELGIUM
> > > > Office, but invoice is linked to fr office, BELGIUM office .. I may
> be
> > > > wrong but I have two customer that do this actually and I don't know
> > how
> > > > to setup this in v7. With rapahel branch I just have to set contact
> to
> > > > "accounting manager" and partner to fr Office for example. But yes we
> > > > have to link openchatter, email and commication to contact_id instead
> > of
> > > > partner id. Like you said rename partner_id by contact in module take
> > > > 10min ;)
> > >
> > > Like in v6.1: you create several accounting manager, one for each
> > > company. (or you install base_contact) Please note that it does not
> work
> > > for raphael branch too.
> > >
> > > Side note: Your use case is very strange, I don't think I ever saw an
> > > accounting soft that do that. (I never saw an accounting software that
> > > prints two addresses on an invoice, one for the real company, another
> > > one for the company that should receive it. When there are a second
> > > address on invoices, it's for delivery address)
> > >
> > >
> > > > 2) Invoice issue and task on timesheet.
> > > >
> > > > - Create a contract (annual support contract) with company ACME. You
> > > define that support cost 60 EUR / hours.
> > > > - Check task and issue on this contract and invoice on timesheet.
> > > >
> > > > Now a man (or woman !) call me because he/she has a problem. I create
> > an
> > > > issue assigned to me, and contact Miss Anna who want to have adresse
> on
> > > > openerp in different tables. I work on it and record my work time.
> As I
> > > > can have more than one open project with ACME, and as OpenERP set it
> to
> > > > mandatory, I need to record my time on a project/analytique account.
> > But
> > > > a...

[Fabien (Open ERP) (fp-tinyerp)]

> group task by partner_id :
>
> ->
> http://www.youtube.com/watch?v=ABcvCnEYhBI&list=PLDo85hjMzeJN2atAdrxsYH5rHxGdc8apo&index=4
>
> really great data model ...

As we said, we think partner_id is the right granularity in a lot of objects for the group_by operations.

If a user records 5 issues:
  - 2 for "Acme, John Doe"
  - 3 for "Acme, Marc Levy"

We think it's normal that, if the user asks a group_by he gets a result consistent with what he recorded:
  - 2 for "Acme, John Doe"
  - 3 for "Acme, Marc Levy"

Not only, it's sometimes what he wants in terms of reporting, but it's surely what he wants if he uses group_by to reorganize documents using drag&drop in the kanban.

Having said that, we also agree that, for some objects you may want, in addition, another type of group_by, which is by commercial_id, not by partner_id. The implementation is trivial as it's just adding a commercial_id fields.related on the object, if you need that.

Fabien

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

[Fabien (Open ERP) (fp-tinyerp)]

Nicolas,

Just a note to say that these scenario "group_by" have been identified and reported in the spreadsheet with all scenario (it's even in the description of this bug):
    http://bit.ly/10WPN5S

We did scenario on a few objects (invoices, SO) but scenario 1..6 can, of course, be duplicated for every object. (when something is identified due to the principle, they are chances that it appears on all documents)

We just didn't do it as the spreadsheet would become very big. What we can do is to take a decision on which object we absolutly need to add a fields.related

Sent from my iPad

On 16 Apr 2013, at 01:23, Nicolas JEUDY <email address hidden> wrote:

> Contract test:
>
> Group contract by parnter:
>
> ->
> http://www.youtube.com/watch?v=DDZWQxFI3xE&list=PLDo85hjMzeJN2atAdrxsYH5rHxGdc8apo&index=5
>
> How can I manage contract and contact on contract ? who will receive
> contract document ? where can I encode this ? Sorry but you need two
> fields, or can you say how I can manage this ?
>
> --
> 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
>
> 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==
>
> ...

[Cristian Salamea (ovnicraft)]

On Tue, Apr 16, 2013 at 12:31 AM, Fabien (Open ERP) <email address hidden> wrote:

> > group task by partner_id :
> >
> > ->
> >
> http://www.youtube.com/watch?v=ABcvCnEYhBI&list=PLDo85hjMzeJN2atAdrxsYH5rHxGdc8apo&index=4
> >
> > really great data model ...
>
> As we said, we think partner_id is the right granularity in a lot of
> objects for the group_by operations.
>
> If a user records 5 issues:
> - 2 for "Acme, John Doe"
> - 3 for "Acme, Marc Levy"
>
> We think it's normal that, if the user asks a group_by he gets a result
> consistent with what he recorded:
> - 2 for "Acme, John Doe"
> - 3 for "Acme, Marc Levy"
>
> Not only, it's sometimes what he wants in terms of reporting, but it's
> surely what he wants if he uses group_by to reorganize documents using
> drag&drop in the kanban.
>
> Having said that, we also agree that, for some objects you may want, in
> addition, another type of group_by, which is by commercial_id, not by
> partner_id. The implementation is trivial as it's just adding a
> commercial_id fields.related on the object, if you need that.
>
>
>
@Fabien, here is not "if we need it add it" a related field, IMO group by
ACME is most common action used, please ask users & partners.
or when you group by partner your partnerships sales you see now 2 for
Contact1, 3 for Contact2 ?
Most used feature wants to see by company not by contact.

This happens in SO, PO, CRM, Invoices, etc. all business document, here you
are telling us to group by ACME i need add related field in all objects ?

Regards,

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

[Nhomar - Vauxoo (nhomar)]

Good... Well to work in verify all of them....

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

> Nicolas,
>
> Just a note to say that these scenario "group_by" have been identified and
> reported in the spreadsheet with all scenario (it's even in the description
> of this bug):
> http://bit.ly/10WPN5S
>
> We did scenario on a few objects (invoices, SO) but scenario 1..6 can,
> of course, be duplicated for every object. (when something is identified
> due to the principle, they are chances that it appears on all documents)
>
> We just didn't do it as the spreadsheet would become very big. What we
> can do is to take a decision on which object we absolutly need to add a
> fields.related
>
> Sent from my iPad
>
> On 16 Apr 2013, at 01:23, Nicolas JEUDY <email address hidden> wrote:
>
> > Contract test:
> >
> > Group contract by parnter:
> >
> > ->
> >
> http://www.youtube.com/watch?v=DDZWQxFI3xE&list=PLDo85hjMzeJN2atAdrxsYH5rHxGdc8apo&index=5
> >
> > How can I manage contract and contact on contract ? who will receive
> > contract document ? where can I encode this ? Sorry but you need two
> > fields, or can you say how I can manage this ?
> >
> > --
> > 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
> >
> > 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 mu...

[Nhomar - Vauxoo (nhomar)]

@cristian...

I am Totally agreed with you,

did you read the second part of the Fabien's answer?

Please support us, in the link the He shared he ask for the verification in
all places we nee them mandatory.

2013/4/16 Cristian Salamea (Gnuthink) <email address hidden>

> On Tue, Apr 16, 2013 at 12:31 AM, Fabien (Open ERP) <email address hidden>
> wrote:
>
> > > group task by partner_id :
> > >
> > > ->
> > >
> >
> http://www.youtube.com/watch?v=ABcvCnEYhBI&list=PLDo85hjMzeJN2atAdrxsYH5rHxGdc8apo&index=4
> > >
> > > really great data model ...
> >
> > As we said, we think partner_id is the right granularity in a lot of
> > objects for the group_by operations.
> >
> > If a user records 5 issues:
> > - 2 for "Acme, John Doe"
> > - 3 for "Acme, Marc Levy"
> >
> > We think it's normal that, if the user asks a group_by he gets a result
> > consistent with what he recorded:
> > - 2 for "Acme, John Doe"
> > - 3 for "Acme, Marc Levy"
> >
> > Not only, it's sometimes what he wants in terms of reporting, but it's
> > surely what he wants if he uses group_by to reorganize documents using
> > drag&drop in the kanban.
> >
> > Having said that, we also agree that, for some objects you may want, in
> > addition, another type of group_by, which is by commercial_id, not by
> > partner_id. The implementation is trivial as it's just adding a
> > commercial_id fields.related on the object, if you need that.
> >
> >
> >
> @Fabien, here is not "if we need it add it" a related field, IMO group by
> ACME is most common action used, please ask users & partners.
> or when you group by partner your partnerships sales you see now 2 for
> Contact1, 3 for Contact2 ?
> Most used feature wants to see by company not by contact.
>
> This happens in SO, PO, CRM, Invoices, etc. all business document, here you
> are telling us to group by ACME i need add related field in all objects ?
>
>
> Regards,
>
> >
> > Fabien
> >
> >
> > >
> > > --
> > > 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
> > >
> > > 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. manu...

[Nhomar - Vauxoo (nhomar)]

Hello.

I think the Hypotesis is incomplete.

Hypothesis
ACME (is_company)
   - John Doe (Invoicing)
- Marc Levy (contact)
- Warehouse X (delivery)

Should be more complicated to cover all scenarios:

Hypothesis
ACME (is_company)
   - John Doe (Invoicing)
- Marc Levy (contact)
- Warehouse X (delivery)
   - Pedro Pérez (Invoicing)
#[To Know if from the link i am able to select both of them]
- Luis Ramirez (default)
#[To allow see what happen when a default is present]
- Warehouse Y (delivery)
#[To considere several Shipping address in some cases have more than one
need a Question and not take the "contact@delivery[0]"]
- Peter landberg (is_company)
#[This is what we got in V6.1 when relate 2 partners, now for useabilities
reason some fields are hidden, and we lost this feature.]
  - Check Department (invoice)
- Warehouse W (delivery)
#[This is to understand a complex partner organization (what we have
dominated in México on 6.1)]

2013/4/16 Nhomar Hernández <email address hidden>

> @cristian...
>
> I am Totally agreed with you,
>
> did you read the second part of the Fabien's answer?
>
> Please support us, in the link the He shared he ask for the verification
> in all places we nee them mandatory.
>
>
> 2013/4/16 Cristian Salamea (Gnuthink) <email address hidden>
>
> On Tue, Apr 16, 2013 at 12:31 AM, Fabien (Open ERP) <email address hidden>
>> wrote:
>>
>> > > group task by partner_id :
>> > >
>> > > ->
>> > >
>> >
>> http://www.youtube.com/watch?v=ABcvCnEYhBI&list=PLDo85hjMzeJN2atAdrxsYH5rHxGdc8apo&index=4
>> > >
>> > > really great data model ...
>> >
>> > As we said, we think partner_id is the right granularity in a lot of
>> > objects for the group_by operations.
>> >
>> > If a user records 5 issues:
>> > - 2 for "Acme, John Doe"
>> > - 3 for "Acme, Marc Levy"
>> >
>> > We think it's normal that, if the user asks a group_by he gets a result
>> > consistent with what he recorded:
>> > - 2 for "Acme, John Doe"
>> > - 3 for "Acme, Marc Levy"
>> >
>> > Not only, it's sometimes what he wants in terms of reporting, but it's
>> > surely what he wants if he uses group_by to reorganize documents using
>> > drag&drop in the kanban.
>> >
>> > Having said that, we also agree that, for some objects you may want, in
>> > addition, another type of group_by, which is by commercial_id, not by
>> > partner_id. The implementation is trivial as it's just adding a
>> > commercial_id fields.related on the object, if you need that.
>> >
>> >
>> >
>> @Fabien, here is not "if we need it add it" a related field, IMO group by
>> ACME is most common action used, please ask users & partners.
>> or when you group by partner your partnerships sales you see now 2 for
>> Contact1, 3 for Contact2 ?
>> Most used feature wants to see by company not by contact.
>>
>> This happens in SO, PO, CRM, Invoices, etc. all business document, here
>> you
>> are telling us to group by ACME i need add related field in all objects ?
>>
>>
>> Regards,
>>
>> >
>> > Fabien
>> >
>> >
>> > >
>> > > --
>> > > 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
>> > >
>> > > ...

[Nicolas JEUDY (njeudy)]

@fabien:

# Note also that the propagation of context changed recently in the web client. Olivier was working on it today. So, the creation of # a supplier may not create contacts as "supplier." Be sure the contact as the checkbox set "Is a supplier"

No fabien, context and duplication data is responsible of this. If I leave end user to check and uncheck boxes (customer, suppliers) how can I be sure my data are ok ?

you imagine, if I make business with asustek I have to check customer, and have to go to all his contact to check customer to ? that's a joke ?

Partner (commercial entity) is a customer, suppliers ... and contact are just contact for this suppliers, customers. I your model you should add is_suppliers and is_customer to the automatic duplicating data function. And this appears on lots of object (be sure I will do video to show you and not just say we need to semantic fields)

[Michael Telahun Makonnen (mmakonnen)]

In replyt #156 @fabien said:
"John Doe, Acme" is a first-class object, not "John Doe". If you want to
manage "John Doe" as a person, you need base_contact module (it's not
related to our solution, it's the same in v6.1 and in raphael's
proposition too)."

Apologies if this might be a slight digression, but I can't let this comment just pass by without responding.

I will say this again: this is the result of a broken data model. There is no reason, technical or otherwise, for this behavior. There is no such thing as "John Doe, Acme". There is only John Doe, who at a particular moment in time works for Acme, and at another time works for XYZ Widgets, and then later on starts his own business. This is the real-world model that OpenERP should be modeling, and this is the model that is most intuitive to any normal user.

While I have not made a very deep analysis, I suspect that you could avoid this "John Doe, Acme" business if you stored both the relation to res.partner *and* also copied the current address of the partner to the invoice. So instead of just partner_id, you would also have a couple of text fields for address and email. This would completely avoid the need to get the address from the res.partner object every time you accessed it. Then, it doesn't matter if John Doe changes jobs or whatever because the address, and any other pertinent temporary data you need, is stored in the invoice itself. And if you think about it, this makes a lot of sense because you only need John Doe's address at the time that you create and send the invoice. Whether you look at the invoice again tomorrow or next week or ten years from now you are only interested in John Doe's address at the time that you invoiced him/his company. Said another way: if you are looking at an invoice from 10 years ago you are only interested seeing John Doe's address at the time that you invoiced him, not his current address. The following scenario would work out of the box with just one John Doe record in res.partner:
1. Invoice John Doe @ Acme, Inc
2. Invoice John Doe @ XYZ Widget, Inc
3. Invoice John Doe @ John Doe, Inc.

[Olivier Dony (Odoo) (odo-openerp)]

On 04/16/2013 08:40 AM, Nicolas JEUDY wrote:
> No fabien, context and duplication data is responsible of this. If I
> leave end user to check and uncheck boxes (customer, suppliers) how can
> I be sure my data are ok ?

It's perfectly valid to have a company that is both a supplier and a customer,
and in that context some of the company's contacts might be "customers" only
while others are preferably "suppliers". Or any mix of both.
This is not something the system can decide on its own or should blindly
synchronize.

However the system can provide useful defaults:

- new customers are frequently created from various places (CRM etc.), so the
default for "is_customer" is True. No manual action needed.
- when you create a new partner on-the-fly while you create a purchase order,
the "is_supplier" flag is set to True by default on it (and on its company if
you create the company on-the-fly as well).
- when you add new contacts on a supplier company, the system can automatically
set 'is_supplier' to True on the contacts (this is the initial default but you
can manually change it later, there's not autosync!)

The two latter cases where not always behaving as expected due to technical
details in the way context propagation works. This is now fixed (see commit
4934 on the server MP if you want the details, then wait ~20min till it's built
by runbot if you want to test).

[Nicolas JEUDY (njeudy)]

#odony: I will test this.

Are you ok with the fact that:

- if partner is customers, all is contact are customers ?.
- if partner is suppliers, all is contacts are suppliers ?
- if the partner are both ? 1) all is contact are both , 2) user can choose and in this case you should add this on form when creating contact from partner form view. ?

Thanks a lot. I'm not again your proposal (even if I would prefer raphael solution and have to field parnter_id and contact_id) but I would be sure that all very small case work out of the box with your solution. It implies:

- model ok
- form ok
- domaine and context ok
- we can reproduce all scenario without bug out of the box (and I will do video to check this)

[Daniel Reis (dreis-pt)]

Fabien, Olivier,

Everyone agrees that the new Partner model is a step in the right direction.

But let's be pragmatic: localizations are not ready to deal with company
contacts in the `partner_id` field, and localization drivers are not ready to
implement the needed changes in a short notice.
I hope you also agree with this.

It's in the best interest of everyone to find a pragmatic solution.
If OpenERP Partners and Customers see this as a blocking issue, it doesn't
matter if the new model is better or not:
Customers will be held back in 6.1, and that's going to seriously hurt
OpenERPs OPW and migration revenue.

So it's not just about "doing what's right".
It's about a very real menace to Partner's ability to do business and sell OPW.
And it's also a very real business and revenue problem for OpenERP SA.

We're in a deadlock where OpenERP is seeing the half-full glass and
Community is seeing the half-empty glass.

I suggest a two step solution to get out of this deadlock:

A) A v7 immediate solution keeping backward compatibility with 6.1 and current
localization code. Current localization customers will be able to immediately
migrate to v7, and OpenERP can secure OPW and migration revenue, and reduce
the pre-v7 maintenance burden.

B)A v7.1 definitive solution, fully implementing the new Partner model vision,
now extensively discussed and tested with the community.

Regarding A), it must be acknowledged that localizations, including those
already migrated to v7, are *not* ready for the new Partner semantics.
In the cases where customers are using v7, `partner_id` is being used
exclusively for companies. Like it or not, they are using a crippled down
version of what OpenERp intended.

An idea could be to create a v7 module `base_partner_compatibility`, that enforces
domains on `partner_id` fields so that current localization code can run
unchanged on v7. Or some better idea from what is being discussed.

Yes, this does not acknowledge the model change, will prevent customers to
benefit from what the new model has to offer, and might even look wrong to you.
But it can be seen as a short term, transitional change, to allow customers to
embrace v7 right now, and give localizations time to properly prepare for the
new model on 7.1.

Regarding B), if Partners now have a backward compatible solution addressing
their immediate concerns with v7, they will be much more open for the new
model's discussion, since we will then be discussing a next version's design
and not on a fix for a stable version. Otherwise, 6.1 compatibility concerns
will inevitably cripple back and prevent the discussion to go deeper.

It's OpenERP's interest that Partners and Customers fully embrace v7
as soon as possible. Community localization are critical for OPW customers,
thus for OpenERP's OPW revenue.

And they need time to fully adopt a new model.

Let's do this in two steps:
- v7 "fix" as an optional module enforcing the 6.1 semantics, perhaps at the cost of part of the new functionality.
- v7.1 fully embracing a thoroughly discussed new model.
- v8 work in trunk could go on unaffected.

[Erwin van der Ploeg (BAS Solutions) (erwin-bassolutions-deactivatedaccount)]

@Oliver: Do i understand that you state that a contact of a customer is automatically also a customer? I find that strange. I have lot's of contacts at customers, but the do not buy anything. No the are not allowed to buy anything. Same with suppliers. I have contact at supplier for information, but i can't buy from then. To avoid mistakes, I don't want to select them on sales or purchases. BY default a contact is a contact, nothing more.

[Fabien (Open ERP) (fp-tinyerp)]

On 04/16/2013 12:15 PM, Erwin van der Ploeg (Endian Solutions) wrote:
> @Oliver: Do i understand that you state that a contact of a customer is
> automatically also a customer? I find that strange. I have lot's of
> contacts at customers, but the do not buy anything. No the are not
> allowed to buy anything. Same with suppliers. I have contact at supplier
> for information, but i can't buy from then. To avoid mistakes, I don't
> want to select them on sales or purchases. BY default a contact is a
> contact, nothing more.

No, Nicolas said that, but Olivier said the inverse.

In our proposition:
  - if you create a contact in the context of a purchase, he is supplier
    by default
  - if it's not in the context of a purchase (not from Suppliers menu or
    from RfQ), it's not a supplier by default.

For the same Company, you can have contacts that are suppliers
(salespersons of your supplier) and others that are customers (people
that purchased). OpenERP sets everything correctly by default, but you
can still change the default value.

There are no synchro of "is_supplier", "is_customer" between contacts
which is IMHO an improvement compared to v6.1

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

[Nicolas JEUDY (njeudy)]

@ fabien

I just try to understand how we can setup V7 with the new model and how prepare training for my customer with this new model.

- So I create a supplier, and create a contact that is supplier, I need to create it from purchase order ?
- When you are on partner form (res.partner) are you in suppliers context or in customer context ?

If I understand, if I go to sales, customers agrolait and create a contact, it will be customer by default (I'm in context of sale ?)
and if I go to purchase, suppliers agrolait (wich can be suppliers too) and add a contact, it will be suppliers by default.

Right ?

If a contact is both I need to open it once from sale -> customer -> agrolait -> contact and once from purchase -> supplier -> agrolait -> contact ?

[Erwin van der Ploeg (BAS Solutions) (erwin-bassolutions-deactivatedaccount)]

Ok, that's ok with me, because if i have to make a contact to create a delivery address (I keep finding that very, very strange), then i want to avoid that i forget to uncheck the "is_customer" checbox and someone sends invoice to a delivery address.

I don't know in other countries, but we in NL just have 3 addresses n a company, that is visiting address (where is you company located), postal address, for all correspondence end a delivery address, for receiving deliveries.

A company can also have contacts, but the are just contacts and nothing more.

Aldo a company can have multiple branches and e.g. all deliveries go to branch and all invoices go to HQ.

So 2 questions here:
- Why is a address a contact. It isn't. Most of the times i'm not allowed to putt a contact on the invoice. Now i have all these contacts in my partner list, witch are just addresses of a company. Lots of things a rather don't see. I rather see only companys and consumers.
- How can i connect a branch company to a HQ company. It can't now, can it be after changes?
- When a contact is there just for creating a delivery or invoice address, will it be clearly visible?

Maybe the answer is allready given, but i can't figure it out. Most of the tread is technical stuff.

[Olivier Dony (Odoo) (odo-openerp)]

On 04/16/2013 01:54 PM, Nicolas JEUDY wrote:
> I just try to understand how we can setup V7 with the new model and how
> prepare training for my customer with this new model.

Why don't you just try it with the latest version of the branches on runbot?

> - So I create a supplier, and create a contact that is supplier, I need to
> create it from purchase order ?

- You create a contact on a PO: it will be supplier by default.
- You create a contact with its company on a PO: both will be suppliers by default.
- You create a partner via the "Suppliers" menu: it will be supplier by default.
- You create a contact for a company that is a supplier: it will be supplier by
default.
- You create a partner via the "Customers" menu: it will *not* be a supplier.
- You create a contact for a company that is not a supplier: it will *not* be a
supplier.

- You find that the default values do not match your needs: you change the
supplier or customer flags on any partner (contact or company) and your setting
will stay permanently

> - When you are on partner form (res.partner) are you in suppliers context or
> in customer context ?

If you use the main menu, then the context is clear depending if you clicked on
"Suppliers" or "Customers" menu. If not via these menus nor via a PO/SO, then
you're in no particular context, the generic defaults apply.

> If a contact is both I need to open it once from sale -> customer ->
> agrolait -> contact and once from purchase -> supplier -> agrolait ->
> contact ?

No, if you want any partner to be both, just make sure both the "Supplier" and
the "Customer" checkboxes are checked, editing it from wherever you want. The
context in which it was created only determine the default values.

[Nicolas JEUDY (njeudy)]

@Erwin

I will create some video to test it and try to find how to do, because I
have the same problem, I don't know how to do some very basic setup with
this new model. But I want to test and see if it's ok.

Nicolas JEUDY

Expert Technique et Fonctionnel Système d'Information
TUXSERVICES

22 rue du seminaire - 25170 Pelousey
e-mail : <email address hidden>
mob. : [phone]
http://www.tuxservices.com

2013/4/16 Erwin van der Ploeg (Endian Solutions) <<email address hidden>
>

> Ok, that's ok with me, because if i have to make a contact to create a
> delivery address (I keep finding that very, very strange), then i want
> to avoid that i forget to uncheck the "is_customer" checbox and someone
> sends invoice to a delivery address.
>
> I don't know in other countries, but we in NL just have 3 addresses n a
> company, that is visiting address (where is you company located), postal
> address, for all correspondence end a delivery address, for receiving
> deliveries.
>
> A company can also have contacts, but the are just contacts and nothing
> more.
>
> Aldo a company can have multiple branches and e.g. all deliveries go to
> branch and all invoices go to HQ.
>
> So 2 questions here:
> - Why is a address a contact. It isn't. Most of the times i'm not allowed
> to putt a contact on the invoice. Now i have all these contacts in my
> partner list, witch are just addresses of a company. Lots of things a
> rather don't see. I rather see only companys and consumers.
> - How can i connect a branch company to a HQ company. It can't now, can it
> be after changes?
> - When a contact is there just for creating a delivery or invoice address,
> will it be clearly visible?
>
> Maybe the answer is allready given, but i can't figure it out. Most of
> the tread is technical stuff.
>
> --
> 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
>

[Ana Juaristi Olalde (ajuaristio)]

@Nicolas

Nor do I, as I'm telling on my comments #119 and #134.
Suposed you and me, we are a kind of "advanced users", as consultants... how are we going to deal with final "basic" customers trying to convince them with arguments we don't believe on?

Simplicity was a heavy argument to move to 7.0 but it seems the usability gained on widgets as been conceptually lost. I see it really difficult in any way or solution to be adopted. Much difficult if adopted solution is not the best one.

Last post for me on this thread also. IMHO: battle has been lost and we abandon the war at this point.

Thank you everybody:

Ana

[Luc De Meyer (Noviat) (luc-demeyer)]

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.

We already submitted a suggested solution to OpenERP two months ago (cf. https://code.launchpad.net/~luc-demeyer/openobject-addons/7.0-partner-accounting-fix/+merge/149167) and we run a production site with this temporary patch but we also reverted back to 6.1 for several projects until we have a view on a real solution to this issue.

I see many good suggestions in this track and I personnally believe that the suggestion of Raphael Vali is the best way forward.

@Fabien, @Olivier,

What about organising a democratic poll amongst your official partners in stead of inventing a solution that may not get adopted by this channel that at the end of the day needs to generate the revenue required to fund the future of OpenERP ?

Regards,
Luc

[Olivier Dony (Odoo) (odo-openerp)]

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.

Luc please, let this discussion not be about fighting or "being right". I hope
we're all collaborating in order to do what is best for the product, and I
think we've done a lot of progress here so far, despite frustrations.

> We already submitted a suggested solution to OpenERP two months ago (cf.
> https://code.launchpad.net/~luc-demeyer/openobject-addons/7.0-partner-
> accounting-fix/+merge/149167) and we run a production site with this
> temporary patch but we also reverted back to 6.1 for several projects
> until we have a view on a real solution to this issue.

It seems like the various issues your patch wanted to achieve are covered by
our current merge proposals. In order to make further progress the best would
be to test them (the branches are linked to this thread and it is also
available on runbot, look for 7.0-fix-contact-company-handling).

As a reminder:
- the rationale for the new model is explained here: http://bit.ly/17eMp8F
- a list of important cases and test results is here: http://bit.ly/10WPN5S

> I see many good suggestions in this track and I personnally believe that
> the suggestion of Raphael Vali is the best way forward.

The solution presented by Raphael does not replace a proper fix of the 7.0
branches right now and for the future.
You could see it as an extra 6.1-compatibility adapter on top of the official
7.0 branches, for those who can't properly deal with the migration of their
modules to the 7.0 model now. Some people may want to use it, but we can't
accept that in the official addons and we can't recommend it, because it can
result in inconsistencies, misleading data, possible loss of contact
information and possibilities of invalid business flows (details on the MPs)
And you would still have to deal properly with the migration to the 7.0 model
at some point.

So if you are really considering this solution, you must be sure you actually
analyze it properly and review the merge proposal to see the consequences.

But be sure to also test/review our merge proposals, because these are
mandatory for correcting/improving a lot of important things in 7.0,
irregardless of what you do with Raphael's work.
There may be important points that we could still improve thanks to your
feedback, so it's really worth your time.

Many thanks!

[Nicolas JEUDY (njeudy)]

@odony:

Raphael proposal and your proposal are both two solution for the problem.
We have to test both of them a find the best. If both meets requierments we
will have to choose or perhaps we will have the choice (install one or
other).
I'm not agree with you on this:

"" The solution presented by Raphael does not replace a proper fix of the
7.0
""branches right now and for the future.

The solution raphael propose is one solution you just don't want to try ..
We will post vidéo for all scenario to show you it works, but don't say now
this is not the solution. I wil test both, and write an advice on both.
them we can choose.

I think We (partner, community) spend time to test solution, just hope you
will listen to us if at the end raphael solution is the best. I have no
advice now, I will try all scenario and real case to say ok. And most of
partner should do this I think to have a good product for all our customers
..

Nicolas JEUDY

Expert Technique et Fonctionnel Système d'Information
TUXSERVICES

22 rue du seminaire - 25170 Pelousey
e-mail : <email address hidden>
mob. : [phone]
http://www.tuxservices.com

2013/4/17 Olivier Dony (OpenERP) <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.
>
> Luc please, let this discussion not be about fighting or "being right". I
> hope
> we're all collaborating in order to do what is best for the product, and I
> think we've done a lot of progress here so far, despite frustrations.
>
>
> > We already submitted a suggested solution to OpenERP two months ago (cf.
> > https://code.launchpad.net/~luc-demeyer/openobject-addons/7.0-partner-
> > accounting-fix/+merge/149167) and we run a production site with this
> > temporary patch but we also reverted back to 6.1 for several projects
> > until we have a view on a real solution to this issue.
>
> It seems like the various issues your patch wanted to achieve are covered
> by
> our current merge proposals. In order to make further progress the best
> would
> be to test them (the branches are linked to this thread and it is also
> available on runbot, look for 7.0-fix-contact-company-handling).
>
> As a reminder:
> - the rationale for the new model is explained here: http://bit.ly/17eMp8F
> - a list of important cases and test results is here:
> http://bit.ly/10WPN5S
>
>
> > I see many good suggestions in this track and I personnally believe that
> > the suggestion of Raphael Vali is the best way forward.
>
> The solution presented by Raphael does not replace a proper fix of the 7.0
> branches right now and for the future.
> You could see it as an extra 6.1-compatibility adapter on top of the
> official
> 7.0 branches, for those who can't properly deal with the migration of their
> modules to the 7.0 model now. Some people may want to use it, but we can't
> accept that in the official addons and we can't recommend it, becaus...

[Fabien (Open ERP) (fp-tinyerp)]

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

[Nhomar - Vauxoo (nhomar)]

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

[Nicolas JEUDY (njeudy)]

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

http://goo.gl/4Zrp5

[Nicolas JEUDY (njeudy)]

@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 :)

[Nicolas JEUDY (njeudy)]

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 :)

[Nhomar - Vauxoo (nhomar)]

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

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

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.

[Fabien (Open ERP) (fp-tinyerp)]

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: [phone]
Fax: [phone]
Web: http://openerp.com

[Luc Maurer @ Camptocamp (lmaurer-c2c)]

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

[Nicolas JEUDY (njeudy)]

@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. : [phone]
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 ...

[Nicolas JEUDY (njeudy)]

@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. : [phone]
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
>

[Alexandre Fayolle - camptocamp (alexandre-fayolle-c2c)]

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,

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

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.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

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.

[Cristian Salamea (ovnicraft)]

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: [phone]
> Fax: [phone]
> 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 ...

[Maxime Chambreuil (http://www.savoirfairelinux.com) (max3903)]

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

[Fabien (Open ERP) (fp-tinyerp)]

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

[Christophe Combelles (ccomb)]

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

[Christophe Combelles (ccomb)]

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.

[Ana Juaristi Olalde (ajuaristio)]

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

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

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.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

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

[Fabien (Open ERP) (fp-tinyerp)]

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.

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Ahhhh sorrrrry,

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

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

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.

[Olivier Dony (Odoo) (odo-openerp)]

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!

[Nhomar - Vauxoo (nhomar)]

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

[Luc Maurer @ Camptocamp (lmaurer-c2c)]

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

[Nhomar - Vauxoo (nhomar)]

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

[Michael Karrer (michaelkarrer81)]

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?

[Cristian Salamea (ovnicraft)]

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,

[Olivier Dony (Odoo) (odo-openerp)]

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.

[Olivier Dony (Odoo) (odo-openerp)]

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

[Peter Langenberg (peter-langenberg)]

@odo important for us

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

[Jacques-Etienne Baudoux (jbaudoux)]

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