Comprendiendo como Odoo funciona en Argentina - módulo l10n_latam_base

Gustavo Orrillo
- 30/07/2022 - 3 min. de lectura

Creo que se necesita documentar como Odoo funciona en Argentina. Ignacio hizo un fantástico trabajo con su libro documentando como funciona y como se implementa Odoo en Argentina; y creo que eso es un punto de partida. Quiero documentar mejor como funciona Odoo Community en Argentina, para poder comprender mejor su funcionamiento. Es algo que carece la comunidad y se debe afrontar. De la misma manera que debemos comprender como funciona mejor el módulo pyafipws (dudo que muchos de los que leen este blog utilicen la versión Enterprise, es por eso que su conocimiento de pyafipws es fundamental). Así que manos a la obra. 

Si listamos los módulos de Argentina o Latinoamérica que ofrece Odoo Community, veremos la siguiente lista


Los tres primeros módulos son los que se utilizan en la contabilidad Argentina, así que vamos a empezar a documentar el módulo l10n_latam_base.

Los modelos

Se define el modelo l10n_latam.identification_type y ahí encontramos que tiene un campo muy simpático, el cual es is_vat. También se agrega el campo country_id (en el caso que alguien tenga la excéntrica idea de tener una sola base de datos con compañías de dos paises, idea que en los papeles parece buena pero cuando uno se encuentra con algo llamado factura electrónica le hace rogar volver el tiempo atras y tener una base de datos por cada país). 

Con respecto al modelo res.company se extiende el create para asignarle el CUIT (o la identificación que es VAT del país de la compañía) a la compañía. Mirenlo, es muy interesante como lo hace:

@api.model
def create(self, vals):
    """ If exists, use specific vat identification.type for the country of the company """
    country_id = vals.get('country_id')
    if country_id:
        country_vat_type = self.env['l10n_latam.identification.type'].search(
            [('is_vat', '=', True), ('country_id', '=', country_id)], limit=1)
        if country_vat_type:
            self = self.with_context(default_l10n_latam_identification_type_id=country_vat_type.id)
    return super().create(vals)

Es muy interesante como se hace (y creo que debemos tener un post sobre como extender los métodos create, write y unlink de los modelos; son una herramienta fundamental para todo desarrollador de Odoo).

Y al partner le agrega el campo vat junto con el tipo de identificación principalmente.

Las vistas

Con respecto a las vistas se crean el menú, la acción y la vista para el modelo l10n_latam.identification_type. Y con respecto al partner, sobreescribe el campo vat de la vista del partner principal y lo reemplaza con dos campos; el tipo de identificación y el campo vat (y le da un formato mucho más lindo). También hace que el campo l10n_latam_identification_type_id sea obligatorio si el partner es una empresa (o ente jurídico al que le podés emitir una factura de venta) y el dominio se restringe por los tipos de identificación disponibles para cada país.

<field name="vat" position="after">
    <label for="l10n_latam_identification_type_id" string="Identification Number"/>
    <div>
        <field name="l10n_latam_identification_type_id" options="{'no_open': True, 'no_create': True}"             placeholder="Type" attrs="{'readonly': [('parent_id','!=',False)]}"                              class="oe_inline"             domain="country_id and ['|', ('country_id', '=', False), ('country_id', '=', country_id)] or []" required="True"/>
        <span class="oe_read_only"> - </span>
        <field name="vat" placeholder="Number" class="oe_inline" attrs="{'readonly': [('parent_id','!=',False)]}"/>
    </div>
</field>

Los datos

Por default agrega tres tipos de identificación: Pasaporte, VAT y ID Extranjero

La seguridad

La seguridad hace algo muy interesante, le permite a todos los usuarios leer el modelo l10n_latam.identification_type y solo le permite a los managers modificarla:

"id","name","model_id:id","group_id:id","perm_read","perm_write","perm_create","perm_unlink"
"access_latam_identification_type_all","latam id type all","model_l10n_latam_identification_type",,1,0,0,0
"access_latam_identification_type_manager","latam id type manager","model_l10n_latam_identification_type","base.group_partner_manager",1,1,0,0

El post_init_hook

Después de instalarse el módulo se ejecuta el post_init_hook, en este caso es la función _set_default_identification_type. La cual actualiza (mediante SQL) todos los partners seteando el tipo de identificación a CUIT (o vat del país del módulo).

def _set_default_identification_type(cr, registry):
    env = api.Environment(cr, SUPERUSER_ID, {})
    env.cr.execute(
        """
            UPDATE res_partner
            SET l10n_latam_identification_type_id = %s
        """,
        [env.ref('l10n_latam_base.it_vat').id]
    )

Por último, esto también forma parte de un esfuerzo personal para que la gente lea más el código de Odoo. Al principio puede parecer bastante dificil, pero la realidad es que si uno desea dar un salto de calidad en los conocimientos y productividad con Odoo, no queda otra que dedicarle horas y horas al estudio del código base que brinda Odoo.


Acerca de:

Gustavo Orrillo

Passionate about programming, he has implemented Odoo for different types of businesses since 2010. In Moldeo Interactive he is a founding Partner and Programmer; In addition to writing on the Blog about different topics related to the developments he makes.