SPED Base

Este módulo contiene algunas abstracciones utilizadas por los módulos de SPED

No hace nada por sí solo, pero sirve dentro de los 4 módulos:

• l10n_br_sped_ecd
• l10n_br_sped_efd_icms_ipi
• l10n_br_sped_efd_pis_cofins
• l10n_br_sped_ecf

En especial, cada registro de los módulos de SPED hereda del objeto abstracto l10n_br_sped.mixin que cuenta con vistas automáticas y métodos para importar o escribir registros de los SPED de forma recursiva.

Para cada tipo de archivo SPED, el registro de apertura 0000 hereda también del objeto abstracto l10n_br_sped.declaration que cuenta con métodos para poblar los registros del SPED a partir de las transacciones de Odoo entre las fechas DT_INI y DT_FIN y permite así gestionar los archivos del SPED.

Para gestionar el SPED, basta con crear una declaración del SPED en el menú apropiado. Luego hacer clic en Puxar os Dados do Odoo. Esto va a recorrer el árbol de los registros del SPED y para cada registro va a usar _odoo_domain o _odoo_query para ver si tiene records Odoo para mapear. En caso de que tenga va a llamar al método _map_from_odoo del registro. Luego va a repetir la operación con los registros hijos. En la declaración es posible elegir si usted quiere un único archivo SPED o si usted quiere quebrar el archivo bloque por bloque.

En cada módulo de SPED, existen 2 archivos principales:

• un archivo con el número del leiaute que contiene los modelos abstractos de todos los registros del SPED con todos los campos. Este archivo es gestionado gestionado por la herramienta spedextractor a partir de los pdf de las especificaciones y no debe ser editado manualmente.
• un segundo archivo que contiene la lista de todos registros concretos que heredan de esos primeros modelos abstractos y contiene así todos los campos. Como el mixin de cada registro contiene la versión del leiaute dentro de su nombre, tenemos una forma de soportar varias versiones de los leiautes. Ese archivo de los registros concretos sí debe ser editado manualmente para completar los mappings. Para mapear un registro, se debe implementar el override de esos 3 métodos:
• def _odoo_domain(self, parent_record, declaration): debe retornar un domain que permite la selección de los records Odoo a ser mapeados de acuerdo con el record parente y los datos de la declaración (donde tiene las fechas y la empresa por ejemplo). Para usar ese método _odoo_domain, se debe definir también el atributo _odoo_model
• def _odoo_query(self, parent_record, declaration): en caso de que la selección de los records a ser mapeados no pueda ser obtenida por un domain, puede ser implementado ese override para retornar la query SQL para seleccionar un result set a mapear. En este caso, el record del método _map_from_odoo es un result set de la query Postgres. Si usted no implementa ni _odoo_domain ni _odoo_query e implementa el método _map_from_odoo, el registro va a tener una instancia gestionada para cada declaración. Es el caso del registro I010 de la ECD por ejemplo.
• _map_from_odoo(self, record, parent_record, declaration, index=0) para facilitar, los overrides de los métodos _map_from_odoo de todos los registros, ese ya viene gestionado de forma comentada con todos los campos del registro. Así basta con descomentar el método e implementar cómo es mapeado cada campo a partir del record, parent_record y de los datos de la declaración.