[19.0][ADD] res_company_representative: new module

[NICO-SOLUTIONS]

This Odoo module allows you to manage company representatives and their representative roles.

A representative is a contact (res.partner) assigned to a specific company and representative role. This relationship is managed separately from the partner's parent contact, as a contact being associated with a company does not necessarily mean that they represent the company.

The structured representative data can be used by other modules, for example to display representatives and their roles in external reports or documents.

Features:

• Assign contacts as representatives to companies.
• Assign a representative role to each representative.
• Manage representative roles centrally.
• Define the display order of representatives.
• Define representative sequences per company.
• Prevent duplicate representatives for the same company.
• Display representatives and their roles on the company form.
• Allow the same contact to represent multiple companies independently.

[NICO-SOLUTIONS]

@CRogos
Would you mind reviewing this one when you have some time?

[CRogos]

LGTM, minor suggestions.

[NICO-SOLUTIONS]

@smaddlsoft
Maybe You can have a Look here as well? As this is the next step to include it in 5008...

[smaddlsoft]

Functionally, LGTM.

But: Could you make more explicit here and in the readme what the purpose/use case/possible application (e.g. reports) is and why the standard way of child contacts and using the field position is not enough, or why you think its better outside of the res.partner form but instead in the way you have proposed?

[NICO-SOLUTIONS]

Functionally, LGTM.

But: Could you make more explicit here and in the readme what the purpose/use case/possible application (e.g. reports) is and why the standard way of child contacts and using the field position is not enough, or why you think its better outside of the res.partner form but instead in the way you have proposed?

@smaddlsoft
Thanks for the feedback. I’ll make this a bit more explicit in the README.

Actually, this approach cannot really be modeled properly using res.partner child contacts and the standard position field. One main use case is having structured representative data available (e.g. for external reports/documents), independently of the partner’s parent contact.
The representative is still a res.partner, but being a representative is a relationship to a specific res.company and role — which is why I think it makes sense to keep it on res.company rather than on the partner itself.

This also allows multiple representatives per company and the same partner to represent different companies independently. Pretty much the reason for the separate model in the first place 😉