domingo, 28 de julio de 2013

OpenERP - Localización funcional para Colombia - "Terceros"

La situación


Uno de los detalles que cuidan los editores de OpenERP es el aspecto funcional, buscan entre otras cosas, que la versión oficial incorpore prácticas de negocio estándar o de uso generalizado en diferentes países, como consecuencia de esta política de desarrollo, los requerimientos específicos para cumplir la regulación de un país en particular es una tarea que dejan en manos de los partner oficiales en dicho país y, a falta de estos, en la comunidad de desarrollo local.

De hecho, los módulo de localización que vienen con la versión oficial están limitados a dar respuesta a tres aspectos concretos según las instrucciones dadas por el editor de OpenERP en su sitio de documentación [1]:

  • Plan de cuentas y estructura de impuestos (obligatorio para ser aceptado por OpenERP)
  • Interfaces de importación y exportación de movimientos bancarios
  • Reportes obligatorios exigidos por las leyes del país (contables y de impuestos) 


Así las cosas, es normal que la versión oficial no responda de manera adecuada a las exigencias legales de muchos países en aspectos contables, tributarios (impuestos) y comerciales, incluso aún de aquellos países para los cuales existe módulo de localización en la versión oficial que distribuye OpenERP.  Ese es el caso de Colombia.

Hay países que han logrado consolidar una comunidad de desarrollo local gracias al liderazgo de los partner oficiales o de empresas que sin ser partner prestan servicios alrededor de OpenERP.  Un buen ejemplo puede ser España, varias empresas se encargan de mantener la localización funcional de dicho país y de actualizarla cada que se lanza una nueva versión de OpenERP.

Infortunadamente no ocurre lo mismo en Colombia, si bien hay varias ramas de localización en launchpad, esto parece ser más una evidencia de desarticulación de los actores interesados en OpenERP que iniciativas orientadas a la promoción de una comunidad sólida de desarrollo local que asuma la tarea de garantizar una localización funcional de calidad aceptable.

El grano de arena


Pero como una de las dimensiones del software libre, tal vez la de mayor valor, es su carácter eminentemente constructivo, en lugar de lamentarnos de la situación vamos a hacer lo que consideramos correcto: compartir nuestros conocimientos con la esperanza de que sean útiles a otros y que en esta travesía logremos contagiar unos cuantos a ver si algún día surge de forma natural el espíritu colectivo que hoy está ausente.

Localización funcional de "Terceros"


En lenguaje de OpenERP un "Tercero" es un "Partner", esto es, una persona natural o jurídica (empresa) que mantiene un tipo de relación con la compañía. Son terceros entonces los clientes, proveedores, contratistas, empleados, entre otros.

El análisis de las exigencias legales en Colombia nos lleva a proponer el siguiente contenido localizado para el formulario de captura de datos de terceros:


Características:

  • Tipo de documento: Lista de selección con los tipos de documento aceptados por la autoridad de impuestos (DIAN).  
    • 11 - Registro civil
    • 12 - Tarjeta de identidad
    • 13 - Cédula de ciudadanía
    • 21 - Tarjeta de extranjería
    • 22 - Cédula de extranjería
    • 31 - NIT (Número de identificación tributaria)
    • 41 - Pasaporte
    • 42 - Tipo de documento extranjero
    • 43 - Para uso definido por la DIAN 
  • Número de documento:  Obligatorio (puede usarse el campo ref). 
    • Validar que solo contenga números
    • Validar que el número de caracteres esté entre 6 y 11.
    • No permitir duplicados
  • Dígito de verificación (dv):
    • Validar que el número introducido sea correcto (algoritmo)
    • Obligatorio si "Tipo de documento" es NIT
  • Apellidos y Nombres:  Si el tercero es una persona natural (NO es empresa) deben capturarse en campos separados sus dos apellidos y sus dos nombres:
    • Toda persona natural tiene como mínimo primer apellido y primer nombre (Obligatorios).
    • Los datos capturados se concatenan para ser almacenados automáticamente en el campo "name" (estrategia para evitar modificaciones en los módulos que usan el campo "name" del objeto res.partner - casi todos)
    • Validar que los datos concatenados coincidan con el valor almacenado en el campo "name" (puede ocurrir que no coincidan)
    • Incorporar excepciones para campos obligatorios cuando el tercero (res.partner) es creado desde otro módulo (por ejemplo en la creación de usuarios). 
  • Dirección
    • Archivos XML para el cargue de datos de "Departamentos" y "Municipios" (disponible en los proyectos de localización en launchpad)
    • Los "Municipios" deben estar relacionados con los "Departamentos" (disponible en los proyectos de localización en launchpad)
    • Debe aparecer por defecto "Colombia" en el campo "País" del formulario
    • Remover campos de la dirección que no son de uso común en Colombia

Cuando el "Tercero" es una persona jurídica, los campos de "Apellidos" y "Nombres" se ocultan y en su lugar es mostrado el campo "name":


Con esos pequeños cambios logramos la captura de datos de terceros según las exigencias legales vigentes en Colombia.

Hasta la próxima.


2 comentarios:

  1. Gracias por tus aportes en el conocimiento asía la comunidad las imagenes que veo son de un modulo ya realizado y si es asi donde lo puedo testear

    ResponderEliminar
    Respuestas
    1. La localización del tercero es parte de un módulo en desarrollo para la gestión de consultorios médicos, el trabajo está en progreso.

      Eliminar