Link several addresses on individual partners (not companies)

+1

+1

Thx Guewen for the detailed description of that problem - we are in the same situation, that we receive csv files from an onlineshop, where you can have a different delivery address.

Hello Guewen,

it's a bit hard to believe we integrators have to spot such basic regression 2.5 months after the official stable "LTS release and 1 year after it has been prototyped... Even more when OpenERP SA itself said they were once interested in e-commerce...

I tend to think is_company should really be used to tell if partner is a company or not. For instance we already assumed that in our localization and assimilated is_company with an equivalent is_company field we had before in the localization.
If is_company suddenly now just means "has several contacts", I think several things will be broken badly for a stable LTS release. And then another flag would be required to tell if partner is a company or not, so it would be totally confusing. So for me, let's keep is_company for companies.

So what I suggest is to go with the solution to add a distinct extra flag to tell if partner has several contacts or not and alter the contacts and parent visibility based on that new flag instead of is_company.
Flag name suggestion: has_hierarchy ? Anything better? I prefer it over is_individual, but may be just a matter of taste.

Also, I personally would prefer to see that fixed inside the core. Yes it's a non trivial change. But on the other side, discovering such a regression at this stage is already so critical that IMHO it justifies an exceptional fixing policy. IMHO this is still better than having all existing modules not depending on that new community module and doing wrong assumptions on their own and the ERP been broken in the wild even if locally fixed, but only in some rare salvation community modules.

Guys, sorry to say it, but such bug makes OpenERP looks really ridiculous. There is no point in blogging about lunch or mail modules, saying sorry to SAP loudly, calleing himself an ERP and getting the partner/address thing wrong. </rant>

Raphaël, that's my opinion too.

 - `is_company` is only an indicative flag if the partner is a company (I'm not sure if this flag is necessary or not in the base module)
 - a new field `is_main` or `has_hierarchy` which replace the `is_company` field.

Of course I would like to have such a change in the core. However, schema changes are not accepted in stable releases.

If this change is acknowledged by OpenERP but cannot be applied in version 7, a solution would be to only rename the string of `is_company` to something more general, and really change the field name in the next version. That's always annoying to have such confusing inconsistencies but that's maybe the least invasive fix for the better result.

But the most important here is not the solution by itself, that's the recognizing of this problem by OpenERP and to adopt only one way to fix that rather than several. If OpenERP fixes that itself, we are sure of that; if the community fixes that, we need the guidance of OpenERP not to go in a different way than them in the futures versions.

After extra internal discussion, it seems it would definitely be better to keep the `ìs_company` flag as meaning exactly what its name implies, so that it can be used for legal reasons etc. Please disregard my previous comment (I've hidden it for clarity).

So what should be changed in 7.0: we should make sure nothing prevents having addresses or contacts for a regular partner as well, i.e:
- change the fact that currently if the `is_company` flag is unchecked, all addresses/contacts are discarded after each modification
- review all places where the "is_company" flag is used to make sure it is not exclusive with the presence of children
- review the places where the `parent_id` field is used to make sure it does not preclude having a parent that does not have a `is_company` checked.
- change the mini-form view that is displayed by default for the contacts, e.g. by adding the `use_parent_address` field and make it toggle the extra address fields

Then we should ideally add an extra config option in the settings such as "Allow regular users to have multiple contacts or addresses", associated with a group that makes the contacts visible all the time. This is unfortunately a change in the data model (for the extra setting) and cannot be done in 7.0 without adding an extra module.

For trunk we'll do that in `base` directly, and for 7.0 an extra module should be written to accomplish the same thing.

On 03/08/2013 10:11 AM, Guewen Baconnier @ Camptocamp wrote:
> We now know that we can use the `is_company` field in v7 for the
> 'complex' hierarchies (both companies and individuals).

Sorry Guewen and Alexandre, I think I mislead you in my first comment which I
revised shortly afterwards. On second thoughts and after more internal
discussions we think it is indeed better to have a real `is_company` field with
the natural semantics (making it available for legal purposes etc.). So we
would instead make sure it is possible to have contacts and addresses on a
partner that is not marked as `is_company`, even in 7.0.

This way the semantics of the `is_company` flag would be correct in 7.0
already, and not only in trunk. There is probably no need for a `is_hierarchy`
or `is_complex` flag, it is redundant with the actual presence of children.

We plan to do everything that can be done for that in 7.0 without breaking the
stable policy, and the rest will be done in trunk (adding a config option to
show the addresses/contacts on all partners).

I apologize for the confusion, hopefully this solution works for you as well...

Yep, no worries about that.
I hid my previous answer too :-)

You are right, the `is_complex` flag would be redundant with the presence of children.

That's seems also a good solution to me.

Just a point, how will you determine who is the 'accounting partner'? Use the direct parent_id if such exists and the current partner has no children?
It could maybe be a problem if one want to create a hierarchy of 'simple' partners, they would be mislead with a 'complex' partner with addresses. That's maybe a use case to forbid though.

Still, thanks for your acknowledgement and your intervention on this topic.

Another complex question.

Try this:
.- Create a particular customer named XX, set his address and data
.- Casually this customer is our employe, so create the XX employe and set his (same) data. Try to include a new particular address for this employe, so create one with (same) data.
.- Now... XX is our system user, so create the XX user and attach to the employe.
.- Now... Go to partner list and deactivate all filters.
What you see?
There is at less 3 different partner records for our XX named person. It's almost a chaos having same data replied so many times for same information.

My 2cents.

My Opinion about schema changes policies: IMHO being allowed to make an important change or not is all related to the amount of testing and communication you do around it.

That is: in general you don't kill yourself in manual testing and communication and only do the automatic testing which doesn't have a really big effective coverage. That's why usually you should not make important changes such as schema in a stable release.

That being said, you can still very well do a change and do a ton of testing and communicate around apologizing for the change and explaining why changing is better than letting it broken. Just like you would do if bug is a security fix for instance.

So IMHO, when the software is at this barely mature stage of development, with that kind of regressions inside, sometimes trying to always enforce a policy is stupid and instead efforts should be made to fix the issues.

If OpenERP was as stable and as rigorous as say a Linux Kernel, I would never defend breaking rules. But what I say is that the apparent professionalism given to OpenERP is unfortunately mostly only an apparent surface, so may be it's just better to simply bite the bullet, admit things aren't as serious as it looks yet and fix things while it's time.

Meanwhile I wish one day OpenERP become professional and stable. But to do that, instead of just enforcing apparent policies, roadmaps will need to be published and discussed with the community, not just publish a release note once everything has been screwed by some relatively un-experienced programmer in the dark of a trunk branch may be/may be not stable in a year.

So let's talk about how to improve things in the future. There is supposed to be a 7.1 version a 8.0 version? What is the time frame? what is the roadmap for each release? Speaking about policies, will there be a RC (Release Candidate) this time may be?
Or will you just publish the magic release one day as a surprise with may be some bad magic changes inside and then let things broken under the claim you enforce some professional policy?

Sorry for saying it and please to take that personally. I would love to see things change, but may be it all starts with stopping denial and biting the bullet and being professional in the whole product development cycle, not just when it's too late with the no change policy.

That being said think you for your work and for trying to fix things.

On 03/08/2013 11:05 AM, Guewen Baconnier @ Camptocamp wrote:
> Just a point, how will you determine who is the 'accounting partner'? Use
> the direct parent_id if such exists and the current partner has no
> children? It could maybe be a problem if one want to create a hierarchy of
> 'simple' partners, they would be mislead with a 'complex' partner with
> addresses. That's maybe a use case to forbid though.

The current _find_accounting_partner() method uses the direct parent if the
current one is not a company, and it needs to be improved.

To keep things simple, it could probably go all the way up to the root ancestor
in all cases (ignoring the `is_company` flag). That would work for companies
and for individuals. It would not allow complex hierarchies where different
children can be customers/suppliers and have their own receivable/payable
entries, so making separate partners for these special cases would still be
required. However it seems it would still cover most B2C and B2B cases, while
keeping the logic very simple to understand and use.

Then perhaps in trunk we could refine this behavior by relying more on the
`customer`/`supplier` flags: depending on the kind of journal entries being
generated the system could take the first `customer` or `supplier` parent in
the hierarchy, which would allow making multi-customer/supplier hierarchies.
However to make this robust we should make sure that contacts/addresses are
never flagged as customer/supplier implicitly, and help avoid mistakes by
raising an error when the partner flags aren't properly set at the moment of
generating the journal entries.
It sounds a bit complicated to understand and use properly though, so we need
to make sure it's really useful first.

What do you think?

I actually meant don't take that rant personally of course.

On 03/08/2013 01:42 PM, Ana Juaristi Olalde wrote:
> Another complex question.

Ana, I'm not sure your point is quite related to this bug report. Perhaps it
would be useful to ask this as a separate question on help.openerp.com?
I think the mess you describe was quite possible to achieve in previous OpenERP
versions (very similar mess at least), only now it's in contacts rather than
addresses. Doing the provisioning operations in the right order should solve
the duplication in most cases. I'll be glad to discuss more on a dedicated
question or bug report.

+1
We wont consider moving to v7 until this is fixed the way it was. Why break something that worked.

@ Olivier

About the _find_accounting_partner(), your suggestion that "it could probably go all the way up to the root ancestor
in all cases (ignoring the `is_company` flag)".

This option is not possible for legal reason : you always invoice the company of your contact - not the top group mother company for example.

So, I suggest that the _find_accounting_partner() method works like this : "use the first parent which is a company if the current one is not a company" + in order to handle B2C cases, I suggest to add : "... if none (=no parent ticked as company), use the first parent"

(but I have to assume here that a customer who is a individual person can only have 1 parent - ie : in B2C e-commerce business, a customer can have several addresses but usually do not have parent)

Frederic
Camptocamp

"Ana, I'm not sure your point is quite related to this bug report. "

Anas described issue is DIRECTLY caused by your implemented changes! This and many more still waiting are caused by those unprofessionally made changes. I'm sorry for such words, but cannot describe them more precisely.

Normunds
Alistek Ltd

@olivier: I just wanted to point that in previous version a partner was only created if you needed creating a partner but now, there is several points on system that is duplicating partner record. Several records with same/different data could cause heavy integrity errors on several situations.
So... for me the aproach wouldn't be so bad if it's redesigned somehow but it should be redesigned.

There is 2 different entities:
.- People, needing Name + surname + several data as personal address, job address, Identity card... etc. People and could be employees (needing another different data) or contacts (needing another ones)
.- Company, needing only Name + several other fiscal data (including VAT) + several different addresses where people are related to.
On the other side there is entities you have to invoice to or they invoice to you. This could be companies or people.

The last one you have got addresses, related to people, companies, employeess or whatever other entity you need. 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 that's going to cause yes or yes integrity errors when you need several of them. That's what's happening now.

So.. if the idea is having one single entity including data once but extending this data inheriting it where ever you need, it would be OK but if you try to make one single entity that you have got to duplicate each time you need it again... something it's wrong. And I think the actual aproach it's not covering first scenario but second one.

On older aproachs, this entities where separate and you could use almost as you needed. It was quite clear you could invoice only to companies, you had "contact" aproach, you could reuse "contact" for several addresses, you could reuse address on other areas... Your employes where only employees and if they where also partners it was when you needed it... So, IMHO, the aproach was quite better that it is now.

My 2cents.

+1 for comment #21
"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.
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 nedded.

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

Goran Kliska

Please note: bug 1160365 has been created to specifically discuss other generic issues with the 7.0 partner model. Feel free to post comments there if not directly related to the current bug report.
Thanks for your patience and your constructive feedback!

Note: the related branch lp:~openerp-dev/openobject-addons/7.0-fix-contact-company-handling is somewhat related in broad terms, but does not fix the current issue. (just to be clear on the state of this bug report).

There are any news on this? any solution?

Is there any solution to this high priority problem. I just checked the latest trunk version but the behavior remains the same as in our 7.0 installation. What is the best way to fix the issue?

Are there any progresses?

Maybe if you want to fix this but cannot do it without somehow breaking the inner parts of v7.0, you could consider pushing 7.1 for that, so 7.0 modules do not guarantee to work in 7.1 and everyone is happy and informed.

Waiting for a real fix in the official addons, I use a small module "base_partner_always_multi_contacts" that I have pushed in lp:~akretion-team/+junk/70-usability

This module allows you to have several contacts on partners with is_company=False.