Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Avatar

Re: Partner unicity

by
Eska Yazilim, Levent Karakaş
- 18/04/2018 09:49:01
Vat can be enough for some while others might need more fields. It would be good to have some module like partner_unique_base module with a inheritable search domain function (partner_vat_unique and other modules can extend this domain).

2018-04-18 10:32 GMT+03:00 Johan Van Hirtum <johan@vanhirtum.be>:

Dear Alexis,

 

Even mobile cannot be unique. For example, sometimes you have the same person 2 times as a customer : 1 time as a private person, 1 time as a company with TVA.

 

With kind regards,

 

 

Van Hirtum Johan

 

Van: Alexis de Lattre [mailto:alexis.delattre@akretion.com]
Verzonden: dinsdag 17 april 2018 20:02
Aan: Contributors
Onderwerp: Re: Partner unicity

 

Thank you Alexandre for sharing your experience.

 

2018-04-17 18:54 GMT+02:00 Alexandre Fayolle <alexandre.fayolle@camptocamp.com>:

1. unique mail / phone can be an issue with contacts of customers /
suppliers (you can have an invoicing address with the same phone number
as a contact for instance)

 

My idea is to add unicity only on the 'mobile' field, not on 'phone' nor 'fax'.

 

2. some partners are tricky to deduplicate : the partner of the user and
the partner of the employee (and these may have the same mobile phone
number). When using hr_expense, the partner related to the home address
of an employee is used to issue refunds (and probably the payroll module
does something similar but I've never used it). While the user's
partners may be set as contacts of the company, you must never do that
with the home_address_id of the employee (otherwise the company becomes
the commercial_partner_id of the employee's home address and you are
completely stuck when paying the refund). A consequence of this is that
it is quite tricky to merge the home addresses of employees and user's
partners, and they typically get the same name and adding a follower on
a record adds the wrong one half of the time...)

 

In my deployments, I keep "partners" linked to users with parent_id=False: I don't want them to be contacts of the company (even if it seems the logical thing to do for Odoo users). This avoids problems in the accounting when the partner_id of move lines needs to be a "parent" partner, and you often needs to have the partner of an employee in your move lines (for expenses in particular). With this solution, when I have the "hr" module, I can point the home_address_id of the employee to the partner linked to the user.

 

3. beware of archived partners. On large CRM databases, you will find in
time people moving from 1 company to another. The good practise is to
archive them and create a new partner (otherwise the opportunities
change companies). They may decide to keep their mobile phone number, so
you have to exclude the active=False records from the unicity constraint.


Good point ! Is it possible to have an sql constraint on the 'mobile' phone that exclude active=False records ? For perf reasons, I would prefer to have an sql constraint...

 


4. hr_recruitment: when you have candidates coming from headhunters, you
may have lots of candidates with the same email adress (the one of your
contact in the head hunter cabinet). I've built a tool though for a
company doing HR with odoo to help them find applicants with the same
email or mobile than a given candidate, to help them identify people
applying multiple time (simultaneously or over a period of time).

 

I don't have experience with the module hr_recruitment. I see that the object 'hr.applicant' has a 'partner_id' field, but it is NOT a required field.

 

One point you have not mentionned is the "ref" field. I find it useful
to have it unique (but it can't be used to deduplicate and it is not
required). I've often made this field an accounting field copied on
contacts of a company.


For sure, the 'ref' field should be unique. I have a small usability module that adds this (https://github.com/akretion/odoo-usability/blob/10.0/base_partner_ref/partner.py), but we should have a module that adds the sql_constraint unique(ref) in OCA.

 

This is a difficult task (but a useful one).

 

Yes, when we go in the details, it is not as easy as it seems :(


--

Alexis de Lattre
Akretion France - 35B rue Montgolfier - 69100 Villeurbanne - France
Mail : alexis.delattre@akretion.com
Mobile : +33 6 99 08 92 45

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe


Reference