← Back to team overview

openerp-community team mailing list archive

Request for Inclusion of Module into OCA/partner-contact


*Hello Community, mainly OCA protagonists in this case*

I would like to formally propose a module which I developed yesterday for
the partner-contact repository of the OCA. It has some similarities with
the passport module (from savoirfairlinux), but a somewhat different use
case and therefore different requirements.


In some countries, it is legally necessary to identify a partner by some
kind of legal document. You need to know: Document Type, Document Number,
and probably even a Scan of this Document.

It extends the res.partner class with those three information entities and
adds a document type class which can be csv-preconfigured by localizations.
It furthermore includes two hooks for customized validation-and-formatting
and copy/alteration on a per document type basis. Like this you could not
only validate but for example also include a reminder, that for a specific
document type a scan is mandatory.

*Detailed Use Case:*
To help your understanding, the concrete use case is the one of Colombia,
where we have around 12 different documentation types. Some of them have a
validation algorithm available, such as Personal-ID, Colombian-VAT ("NIT")
or Colombian Foreigners-ID. If it is a so called "commercial person" (can
be natural person or legal entity) it must identifiy with a special
Document (and only this one), called RUT with an ID number called NIT. This
RUT must be shown (a copy) as support at moment of tax declaration in order
to make expenses deductible. Therefore it must be possible to return a
boolean value from the existensce of an uploaded document in order to sort
move-lines into special reporting entities (eg. analytical accounts) for
the tax P&L declaration.
To compare it with other coutries: If a scan of the RUT is registered and
the NIT is extracted and formatted, this situation (copy available  AND
number extracted) would correspond to the existence of a VAT number on this
special partner, so we want to mimic this behaviour which sometimes is
meaningful in other modules. Therfore we want to copy the NIT, transform it
into it's international format (so that it can be also occasionally
validated by python's vatnumber) and copy it to the vat field. This is what
we want to achiev with the copy hook procedure, but which can be used as
any type of procedure with self (res.partner) as readily available input.

I think OCA is the right place, because it is configured mainly
programatically, might be extended to similar use case patterns in other
countries/situations, havs its main use in localization/cusomization, is
kept generic have use cases in other countries and is due tu the modular
design not very difficult to maintain.

It is written in the new api style and works on V8rc1, so far.


   - One known limitation relates to bug [1]
      - Another limitation is that might get fixed easily with the right
      knowledge, that the parent model fields are not acssible on the children
      class identation level, i couldn't figure it out how to do it, maybe with
      the new api this is also a kind of framework limitation and can only be
      fixed by workarounds, I don't know, so I hope someone can
probably help out
      with this. (see TODOs in the code, related: [2])
      - Maybe some GUI improvements, but actually this should probably be
      done at time of customization... (Related: [3])

*The link is:*

Thank you in davance for your assessment. If your result will be positive,
please indicate me the next steps to perform. (I would porbably say, that
the quality assurance can be done on a PR already?)

*Thank you and kind regards*


[1] https://github.com/odoo/odoo/issues/1526

[image: El Alemán S.A.S] <http://www.elaleman.co/>

David Arnold BA HSG / Gerente
315 304 13 68/ david²elaleman.co

El Alemán S.A.S Office: +57 (1) 651 3766 / Fax: +57 (1) 651 3772
CRA 13 93 40 P4, Bogotá, Colombia

[image: Facebook]

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. El Aleman S.A.S
is not responsible for errors or omissions in this message and denies any
responsibility for any damage arising from the use of e-mail. Any opinion
and other statement contained in this message and any attachment are solely
those of the author and do not necessarily represent those of the company.

Follow ups