martes, 23 de diciembre de 2014

Odoo - Localización funcional para Colombia - NIIF


Contexto


La implementación de las Normas Internacionales de Información Financiera -NIIF- es un proceso que apenas está despegando en Colombia.  En términos generales podemos afirmar que tanto las empresas como los Contadores Públicos se enfrentan a un "mundo desconocido", de ahí que sea completamente normal que se lance una pregunta recurrente a los proveedores de software: ¿Este producto "maneja NIIF"?

Un aspecto interesante del asunto es que la pregunta no está bien formulada. Hablando en concreto de Odoo la respuesta al interrogante podría ser un SI categórico, ¿acaso no se usa en países en los que hace rato se adoptaron las NIIF?

La verdadera necesidad en Colombia, originada en la forma particular de adopción de las NIIF, es la generación de información financiera usando dos bases contables diferentes -o estándares si prefieren un término más elegante-: 1) NIIF y 2) Norma local anterior.  Esta condición deberá cumplirse por lo menos durante los siguientes cuatro años al primer período de aplicación de las NIIF, esto es, hasta el 2018 en unos casos y 2019 en otros.

Lo anterior es explicado por la necesidad del Estado de medir el impacto que tendría la aplicación de las NIIF en el recaudo de los tributos nacionales. Para el propósito que perseguimos, con saber esto es suficiente.

Grupos de entidades


Cuando nos referimos a las NIIF podría dar la impresión de que estamos frente a reglas únicas de aplicación general.  La realidad es bien diferente, para comenzar hay que decir que en Colombia se decidió dividir las entidades en tres grupos y para cada uno de ellos se establecieron obligaciones diferentes:

Grupo 1 Aplica Normas Internacionales de Información Financiera - NIIF
Grupo 2 Aplica Normas Internacionales de Información Financiera para Pequeñas y Medianas Empresas - NIIF para PYMES
Grupo 3 Aplica Normas de Información Financiera para Microempresas - NIF para Microempresas

Aquí surge el primer requerimiento de adaptación de Odoo:
Agregar un campo tipo "selection" en el formulario "Compañía" para indicar el grupo al que pertenece la entidad: Grupo 1, Grupo 2 o Grupo 3.
Este campo nos permitirá establecer, más adelante, reglas de comportamiento del sistema en el módulo "Contabilidad y Finanzas".

Registro de diferencias vs Libro Tributario


Hace solo algunos días, el 12 de diciembre, fue expedido el Decreto 2548 para orientar a las entidades acerca de la forma en que deben cumplir con la exigencia de emitir información financiera usando dos bases contables diferentes.  Al respecto se establecen dos alternativas, 1) Llevar un sistema de registro de todas las diferencias que surjan entre la aplicación de las NIIF y la norma local anterior -base fiscal-, y 2) Llevar de forma simultánea el registro de todos los hechos económicos aplicando las NIIF y la norma local anterior -base fiscal-.

La decisión de cuál alternativa elegir va a depender del volumen de transacciones que deben ser representadas de una forma diferente entre las NIIF y la norma local anterior.  Si el volumen es bajo, la mejor alternativa será el registro de todas las diferencias, si el volumen es alto, será el registro de todos los hechos económicos usando las dos bases contables.

Aquí surge el segundo requerimiento de adaptación de Odoo:
Agregar un campo tipo "selection" en el formulario "Compañía" para indicar la alternativa elegida para cumplir con la exigencia de emitir información financiera usando dos bases contables diferentes: Registro de todas las diferencias o Registro de todos los hechos económicos.
Este campo nos permitirá establecer, más adelante, reglas de comportamiento del sistema en el módulo "Contabilidad y Finanzas".

Información financiera vs Bases contables


Para terminar, es preciso hacer notar que a lo largo de esta entrada hemos hecho referencia a dos términos: 1) Información financiera, y 2) Bases contables.  De lo anterior se puede deducir que, para adaptar Odoo a las exigencias relacionadas con la adopción de las NIIF en Colombia, se requerirán cambios en dos características principales: 1) Los informes generados desde el módulo "Contabilidad y Finanzas", y 2) La configuración de cuentas contables y de comprobantes de contabilidad -Diarios, en lenguaje Odoo-.  De esto nos ocuparemos en futuras entradas.

--------------

Advertencia: La especificación de requerimientos sobre la adaptación de Odoo para cumplir las exigencias relacionadas con la adopción de las NIIF en Colombia no pretenden ser un curso de NIIF. Nuestro objetivo está limitado a orientar a los desarrolladores sobre las funcionalidades que deben ser incorporadas en Odoo.

--------------

viernes, 19 de diciembre de 2014

Odoo - Localización funcional para Colombia - Información exógena: Formato 1008

Continuando con la tarea de documentar las especificaciones de requerimientos funcionales para avanzar en la localización de Odoo para Colombia, vamos a abordar un tema de especial interés para las empresas: La información exógena.

La DIAN definió mediante Resolución 000220 del 31 de octubre del 2014 las reglas para la presentación de la información exógena correspondiente al año gravable 2015.  El numeral 18.7 de la la misma -pág 32-, establece los criterios que se deben cumplir en el reporte de los deudores al 31 de diciembre del año gravable, a su vez, el Anexo 24 Formato 1008v7 define la estructura de datos del archivo XML a reportar.

Cuentas a conceptos


La información sobre las cuentas por cobrar a diciembre 31 del año gravable deben ser reportadas a través de cuatro conceptos:

CONCEPTO DESCRIPCIÓN
1315 El valor total del saldo de las cuentas por cobrar a clientes
1316 El valor total del saldo de las cuentas por cobrar a accionistas, socios, comuneros,cooperados y compañías vinculadas
1317 El valor total de otras cuentas por cobrar
1318 El valor total del saldo fiscal de la provisión de cartera, en el concepto 1318, identificándolo con el NIT del deudor

Como este esquema se repite para otros formatos, lo mejor es diseñar un mecanismo genérico de asociación de cuentas contables a conceptos.  En la siguiente imagen se puede observar un posible diseño de interfaz de usuario:



  • Formato: Lista de formatos exigidos por la DIAN
  • Año fiscal: Año gravable sobre el cual se aplica la configuración de conceptos y cuentas.
  • Concepto: Conceptos definidos en la resolución.  Estos han permanecido relativamente estables.
  • Cuentas: Cuentas contables asociadas a cada concepto.  Aquí se deben cumplir dos reglas, a) que las cuentas contables sean del nivel de registro, es decir, diferentes a tipo "Vista", y b) que las cuentas solo puedan ser asignadas a un único concepto.
  • Generar archivo: Cuadro de chequeo para indicar si el archivo debe ser generado en formato csv o xml.
  • Cuantía a reportar: Valor a partir del cual se deben reportar los datos individualizados por tercero.  Las cuantías inferiores a esta cifra se deben acumular en un solo registro, asignando el tercero "CUANTÍAS MENORES".
  • Saldo - Débitos - Créditos: Campos para indicar al sistema la fuente de datos para realizar el cómputo y procesar el archivo.  En el caso del formato 1008 serán los saldos de las cuentas por tercero.

Validaciones


Antes de generar el archivo es recomendable realizar algunas verificaciones:
  • Que todas los movimientos o saldos de las cuentas contables asociadas a los conceptos tengan asignado un tercero, es decir, que el campo "Empresa" esté diligenciado.
  • Que el tercero -Partner- tenga los datos requeridos. Ver: Odoo - Localización funcional para Colombia - Especificación de requerimientos - "Terceros".
  • La verificación de la cuantía a reportar de forma individualizada por tercero debe realizarse tomando todas las cuentas contables asociadas a los conceptos, así por ejemplo, si el tercero tiene saldos en dos conceptos diferentes, cada uno por un valor inferior a la cuantía a reportar, pero sumados los dos supera dicha cuantía, el tercero debe ser reportado de forma individual, no puede acumularse en cuantías menores.

Archivo


El archivo csv debe contener los campos indicados en el Anexo 24 Formato 1008v7

Para ver como debería generarse el archivo xml se puede hacer uso del prevalidador publicado por la DIAN para el año 2013, el cual está disponible en: Información de Relevancia Tributaria vigencia 2013.
       
-----------------------------

¿Algún voluntario para hacer este desarrollo? 

-----------------------------

lunes, 15 de diciembre de 2014

Odoo - Localización funcional para Colombia - Especificación de requerimientos - "Terceros"


Con ocasión de la especificación detallada de requerimientos funcionales para lograr una localización de Odoo aceptable para el contexto Colombiano, hemos decidido ampliar una entrada publicada a mediados del año 2013: OpenERP - Localización funcional para Colombia - "Terceros".

¿Por qué es necesario adaptar la forma como se capturan los datos de "Terceros" en Odoo?


Simple, porque es una necesidad que surge a partir de la obligación de reportar información a la DIAN, y no se trata de una necesidad reciente dado que desde el año 2005 se introdujo en Colombia lo que en jerga técnica conocemos como "Información exógena" o "Medios magnéticos".

Para el año 2015 la DIAN ya definió quienes están obligados a reportar información, así como las características técnicas que ésta debe cumplir, lo hizo a través de la Resolución 000220 del 31 de octubre del 2014 y sus anexos.  El Título V -páginas 20 a 38- de la citada resolución es el que nos interesa debido a que es el que tiene aplicación para la mayoría de potenciales usuarios de Odoo en Colombia.  Una lectura rápida de este título nos permite identificar la estructura de datos requeridos para los terceros, a modo de ejemplo, en el numeral 18.2 Información de pagos o abonos en cuenta y de retenciones en la fuente practicadas, se lee "los obligados a presentar información, por el año gravable 2015, deberán suministrar los apellidos y nombres o razón social, identificación, dirección y país de residencia o domicilio de cada una de las personas o entidades beneficiarias de los pagos o abonos en cuenta...". (Subrayado fuera de texto)

Para tener una visión más precisa acerca de la estructura de los datos a reportar es necesario acudir a los anexos técnicos.  Siguiendo con el ejemplo propuesto, el Anexo 19 Formato 1001v9, establece en el "Formato del contenido" -página 3-, entre otros, los siguientes campos:

  • tdoc - Tipo de documento
  • nid - Número de identificación
  • dv - Dígito de verificación
  • apl1 - Primer apellido del informado
  • apl2 - Segundo apellido del informado
  • nom1 - Primer nombre del informado
  • nom2 - Otros nombres del informado
  • raz - Razón social del informado
  • dir - Dirección
  • dpto - Código departamento
  • mun - Código municipio
  • país - País de residencia o domicilio

Validaciones


En la entrada OpenERP - Localización funcional para Colombia - "Terceros" expusimos algunas validaciones básicas, vamos a profundizar un poco sobre el tema.

El campo "Naturaleza" no es exigido por la DIAN, pero si es útil para realizar algunas validaciones y también para definir, en un futuro, reglas de comportamiento del sistema en el manejo de impuestos.

Recordemos que la naturaleza hace referencia a si el tercero es una "Persona natural" o una "Persona jurídica", esto se puede implementar con un campo tipo "selection".  También es preciso señalar que tanto una persona natural como una jurídica pueden ser marcados como "Is a Company", es decir, ambos pueden ser una empresa con la que tenemos algún tipo de relación comercial y ambos pueden tener "Contactos" asociados.

Dicho lo anterior, veamos las validaciones:

  • Si el tercero es persona natural los campos apl1 y nom1 son obligatorios.
    • Si el tercero es persona jurídica los campos apellidos y nombres deben estar vacíos.  
    • Si el tercero es persona jurídica los únicos tipos de documentos permitidos son "NIT", "Tipo de documento extranjero" y "Para uso definido por la DIAN". 
    • Si el tercero es persona jurídica y el tipo de documento es NIT, el número de documento debe contener 9 dígitos.
    • Los campos tipo de documento y número de documento son obligatorios.
    • Si el tercero es "Persona Jurídica" no puede ser a la vez "Contacto" de otro tercero.  Visto de otra manera, si el tercero es "Persona Jurídica" siempre tendrá marcada la casilla "Is a Company".

    -------------------

    Con lo descrito en esta entrada y en OpenERP - Localización funcional para Colombia - "Terceros" completamos los insumos para realizar las adecuaciones del tercero según los requerimientos 001 a 003 de la "Lista de requerimientos funcionales".

    -------------------

    sábado, 15 de noviembre de 2014

    Integración Odoo y Google Calendar

    ¡Jefe, la reunión del Comité de Ventas a la que me citó se cruza con la presentación del portafolio de servicios al cliente que venimos gestionando desde hace algunas semanas.  Por favor deme instrucciones al respecto!
    "Si en su organización son comunes este tipo de comunicaciones, esta publicación puede resultarle útil".

    En organizaciones de tamaño medio y grande, en las que se tiene una división del trabajo por áreas de responsabilidad, es habitual que los líderes de cada área programen reuniones internas a las que invitan a miembros de su equipo de trabajo y/o a los líderes de otras áreas, bien para alinear al equipo frente a los objetivos de la organización, para evaluar los resultados alcanzados, para compartir políticas institucionales o para cualquier otro asunto de interés.

    Antes de programar una reunión es necesario verificar la disponibilidad de tiempo de los invitados y asegurarse de que la convocatoria no interfiera en sus actividades, por lo menos, que no afecte asuntos que deben ser atendidos de manera prioritaria. 

    Cuando no se planifican de forma correcta las reuniones se pueden presentar problemas de coordinación, como la citación a un miembro del equipo a dos reuniones diferentes en la misma fecha y hora, o la citación a una reunión interna a personas de la organización que en ese momento deben atender asuntos de mayor prioridad, como presentar una producto o informe a un cliente importante.

    Para evitar este tipo de situaciones las organizaciones suelen usar herramientas tecnológicas orientadas a realizar una gestión eficiente de las comunicaciones internas, entre ellas se destacan las soluciones provistas por Google, tales como el correo electrónico y el calendario.

    El escenario descrito ha significado para los miembros de las organizaciones tener que habituarse al uso simultáneo, pero separado, de las herramientas de comunicación interna y los sistemas de apoyo a la gestión empresarial o soluciones ERP.  Lo anterior puede impactar de manera negativa la productividad y eficiencia del equipo de trabajo y, en algunos casos, dar paso al surgimiento de problemas de coordinación debido a que podrían programarse actividades en el ERP que no son registradas en Google Calendar, o viceversa.

    Una de las características más interesantes de Odoo, aunque no siempre valorada en su real dimensión, es precisamente la capacidad de gestionar las comunicaciones internas y externas de manera nativa, esto es, la capacidad de ofrecer en un único entorno de trabajo las herramientas de comunicación completamente integradas a las aplicaciones de negocio.  Una de las funcionalidades que hacen parte de este concepto es la integración y sincronización de Odoo con Google Calendar.

    Veamos cómo hacerlo:

    Activar Calendar en Google API


    El primer paso consiste en activar Calendar API en la consola para desarrolladores de Google: https://console.developers.google.com/project.  

    Ingresamos al proyecto que creamos según las instrucciones de la publicación anterior  "Integración Odoo & Google OAuth".  Una vez dentro buscamos en el menú lateral la opción "APIs y autenticación - APIs".  Veremos dos secciones en el área de trabajo: "APIs  habilitadas" y "Navegar por las API".  Vamos a la segunda, buscamos "Calendar API" y damos clic en ella.


    Se mostrará una pantalla en la que se indica que la API se encuentra desactivada, damos clic en el ícono de activación y luego aceptamos las "Condiciones de servicio de Google APIs".


    Después de este procedimiento podemos verificar en "APIs y autenticación - APIs" que "Calendar API" se encuentre en la sección "APIs  habilitadas".

    Agregar URI de redireccionamiento en Google API


    Buscamos en el menú lateral la opción "APIs y autenticación - Credenciales", clic en "Editar la configuración" y agregar la siguiente URI:

    http://www.example.com/google_account/authentication

    (cambiar www.example.com por su dominio).


    Habilitar Google Calendar en Odoo


    Para habilitar Google Calendar en Odoo vamos a Configuración / Configuración / Configuraciones generales y colocamos los valores de ID DE CLIENTE y SECRETO DE CLIENTE que tenemos en nuestra API de Google.  Aplicamos cambios y listo.



    Sincronizar Calendarios Odoo y Google Calendar


    La integración entre Odoo y Google Calendar nos permite realizar sincronizaciones bidireccionales, de esa forma podemos gestionar de forma eficaz y eficiente las reuniones internas y externas planificadas por la organización.

    Para realizar la sincronización vamos a Mensajería / Organizador / Calendario, veremos el botón "Sincronizar con Google" y debajo de este, las opciones para seleccionar los usuarios sobre los cuales deseamos consultar su "agenda".


    ¡Eso es todo, hasta la próxima!


    lunes, 10 de noviembre de 2014

    Integración Odoo & Google OAuth


    En nuestra publicación anterior explicamos como hacer la instalación de Odoo en Ubuntu 14.04, ahora es el turno de explorar el conjunto de posibilidades que nos ofrece esta solución y por qué no comenzar con las opciones de integración entre Odoo y las herramientas de Google.  

    La primera de ellas es habilitar la posibilidad de que los usuarios de Odoo puedan acceder utilizando sus cuentas de Google.  Esta funcionalidad puede ser de gran valor en aquellas organizaciones que utilizan Google Apps for Work dado que le ahorrará a sus miembros la tarea de tener que recordar un nombre de usuario y una contraseña más.  Además, si se combina con la funcionalidad "Permitir ingreso a usuarios externos", Odoo se encargará de traer los datos del usuario desde Google facilitando así el proceso de creación de usuarios a los administradores de Odoo.

    Habilitando autenticación externa


    El primer paso consiste en habilitar la funcionalidad en Odoo, para ello vamos a Configuración / Configuración / Configuraciones generales y marcamos la casilla "Authentication -- Usar autenticación externa, firmar con google, facebook, ....":


    Una vez aplicados los cambios se mostrará una nueva opción en el menú lateral "Usuarios" denominada "Proveedores OAuth"


    La vista tipo lista muestra tres opciones de autenticación, clic en "Google OAuth2" para ver la vista tipo formulario:


    Para activar la autenticación con cuentas de Google se debe marcar la casilla "Permitido", pero antes es necesario ingresar el "ID de cliente".  Para usuarios de habla hispana es recomendable cambiar el "Cuerpo del mensaje" por "Acceder con google".  

    En los párrafos siguientes explicaremos cómo obtener el ID de cliente.


    Obtener ID desde Google Developers Console


    Para obtener el "ID de cliente" es necesario acceder con una cuenta de Google a su consola para desarrolladores: https://console.developers.google.com/project. En el primer acceso el sitio mostrará la opción para crear un nuevo proyecto: 


    Para la creación de un nuevo proyecto es necesario asignarle un nombre, un ID y aceptar los términos del servicio:


    Luego, desde el menú lateral "Credencials" se podrá crear el ID del cliente:


    Al presionar "Create new Client ID" se mostrará el formulario para configurar la pantalla de autorización que le aparecerá al usuario la primera vez que intente acceder a Odoo con su cuenta de Google.  Se deben diligenciar como mínimo los campos "EMAIL ADDRESS" y "PRODUCT NAME": 


    Después, se muestra un nuevo formulario en el que se debe indicar el tipo de aplicación que usará la opción de autenticación con cuentas de Google, se selecciona la opción "Web application".  

    El paso siguiente es indicar la URI a la que será redirigido el usuario, aquí es importante asegurarse de que la URI sea http://www.example.com/auth_oauth/signin (cambiar www.example.com por su dominio):


    Al guardar los cambios se habrá generado el "CLIENT ID":


    Copiar CLIENT ID en el formulario de Odoo Google OAuth2


    De regreso a Odoo, se copia el código obtenido en el paso anterior, en el campo "Id. de cliente"

    Crear usuario en Odoo


    Terminada la configuración, el procedimiento a seguir es crear usuarios en Odoo y enviarles la invitación a través de la opción "Send an Invitation Email" (si es que Odoo no lo hace de forma automática):

    Nótese que el formulario de usuario tiene una nueva pestaña denominada "Oauth" y que los campos están vacíos:  


    El usuario recibirá la invitación en su correo electrónico con las instrucciones para habilitar su usuario en Odoo:


    Al hacer clic en "Aceptar invitación de ..." será redirigido a la pantalla de consentimiento:


    Después de aceptar, el usuario habrá accedido a Odoo y verá las opciones que el administrador del sistema le haya habilitado, si no le ha definido roles entonces verá solo las opciones de comunicación básica o "Red Social":


    Después del primer acceso del usuario, Odoo habrá obtenido y almacenado las credenciales de autenticación, esto se puede verificar en la pestaña "Oauth" del respectivo usuario:


    A partir de ese momento el usuario podrá acceder a Odoo con su cuenta de Google seleccionando la base de datos y dando clic en la opción "Acceder con google":


    --------------------------------------------------------

    sábado, 1 de noviembre de 2014

    Instalar Odoo 8 en Ubuntu 14.04 LTS

    ¡Hemos regresado! 

    Esta vez para compartir con la comunidad de habla hispana una completa guía de instalación de Odoo 8.0.

    Créditos: Esta entrada está basada en la publicación "How to Install OpenERP Odoo 8 on Ubuntu Server 14.04 LTS", del blog "The Open Sourcerer", la cual está amparada con licencia "Creative Commons Attribution-Share Alike 3.0".  Agradecemos al autor el permitirnos a través de esta licencia realizar una obra derivada.

    Paso 1: Crear un usuario del sistema para ejecutar Odoo


    Lo primero que haremos es crear un usuario del sistema.  En Ubuntu un usuario del sistema es diferente a un usuario normal, por lo tanto no aparecerá en las opciones de acceso (login) cuando se arranque el sistema, ni podrá usarse en la terminal o consola.

    El objetivo en este paso es tener un usuario del sistema que ejecute Odoo, para ello le asignamos el directorio en el que instalaremos luego Odoo, en este caso /opt/odoo, si no existe el directorio este será creado automáticamente.  En el caso de que decida utilizar un directorio diferente tenga en cuenta que deberá ajustar algunas instrucciones de esta guía para que se adapten a su propio contexto

    sudo adduser --system --home=/opt/odoo --group odoo

    Paso 2: Instalar y configurar el servidor de base de datos PostgreSQL


    Instalamos PostgreSQL con el siguiente comando:

    sudo apt-get install postgresql

    Pasamos a trabajar con el usuario postgres para tener los privilegios necesarios para configurar la base de datos:

    sudo su - postgres

    Creamos un nuevo usuario de la base de datos.  Este será el usuario que asignaremos en la configuración de conexión a la base de datos del servidor Odoo, tendrá permisos para crear y borrar.

    En este paso deberá asignar una contraseña, no la olvide, la necesitará más adelante:

    createuser --createdb --username postgres --no-createrole --no-superuser --pwprompt odoo

    El sistema le pedirá que asigne una contraseña:

    Enter password for new role: ********

    Y luego que la confirme:

    Enter it again: ********

    Finalmente salimos del usuario postgres:

    exit

    Paso 3: Instalar librerías Python requeridas por el servidor Odoo 


    Con el siguiente comando instalamos todas las librerías necesarias (dependencias) para el correcto funcionamiento del servidor Odoo:


    En este punto debemos seguir un procedimiento especial para obtener e instalar la versión adecuada de la librería wkhtmltopdf.

    Ejecute estos cuatro pasos en la terminal:

    sudo wget http://jaist.dl.sourceforge.net/project/wkhtmltopdf/0.12.1/wkhtmltox-0.12.1_linux-trusty-amd64.deb

    sudo dpkg -i wkhtmltox-0.12.1_linux-trusty-amd64.deb

    sudo cp /usr/local/bin/wkhtmltopdf /usr/bin

    sudo cp /usr/local/bin/wkhtmltoimage /usr/bin


    Paso 4: Instalar el servidor Odoo 


    Obtenemos las fuentes de Odoo desde su página de descargas:

    https://www.odoo.com/page/download

    Seleccionamos las opciones: Platform Sources y Version Odoo 8



    Se descargará un archivo llamado odoo_8.0-latest.tar.gz, lo descomprimimos y cambiamos el nombre de la carpeta que nos crea por server

    Para instalarlo cambiamos el usuario en consola por el que creamos en el Paso 1 y copiamos la carpeta server en el directorio /opt/odoo.

    Para cambiar de usuario:

    sudo su - odoo -s /bin/bash

    Utilizamos el comando cp para copiar la carpeta. 

    cp -R /home/ubicación_de_la_carpeta_server /opt/odoo/

    Al final el directorio quedará así:

    /opt/odoo/server

    Para salir del usuario odoo escribimos exit.

    Paso 5: Configurar el servidor Odoo 


    Creamos el archivo odoo-server.conf en la carpeta /etc/, lo editamos y le asignamos los permisos adecuados:

    Creando el archivo:

    sudo gedit /etc/odoo-server.conf

    El contenido debería quedar así:


    En la línea db_password = False cambiamos False por la contraseña que elegimos en el Paso 2.

    Hemos adicionado una línea en el archivo odoo-server.conf para indicarle a Odoo donde escribir el archivo del log:

    logfile = /var/log/odoo/odoo-server.log

    Asignamos los permisos correspondientes:

    sudo chown odoo: /etc/odoo-server.conf

    sudo chmod 640 /etc/odoo-server.conf

    Las instrucciones anteriores asignan la propiedad del archivo con permisos de escritura al grupo y usuario odoo, y con permisos de solo lectura a los usuarios odoo y root.

    La configuración está lista, es hora de probar si todo anda bien, para ello cambiamos nuevamente el usuario en consola por el que creamos en el Paso 1 :

    sudo su - odoo -s /bin/bash

    Y luego ejecutamos Odoo:

    /opt/odoo/server/openerp-server

    El resultado de la anterior instrucción es el despliegue de varias líneas en la consola como las siguientes:


    Para detener la ejecución del servidor Odoo presionamos simultáneamente las teclas CTRL y C.

    Para salir del usuario odoo escribimos exit.

    Paso 6: Lanzar Odoo al arranque del sistema 


    Haremos que Odoo sea lanzado como un servicio de Ubuntu 14.04, es decir que se inicie y detenga automáticamente cuando se arranque o apague el sistema.

    Para ello creamos un archivo con nombre odoo-server y lo ubicamos en el directorio /etc/init.d/, editamos el archivo para que quede con el siguiente contenido:


    Asignamos el archivo al usuario root y lo hacemos ejecutable:

    sudo chmod 755 /etc/init.d/odoo-server

    sudo chown root: /etc/init.d/odoo-server

    Creamos el directorio con los permisos correspondientes para el archivo log de acuerdo a la configuración realizada en el Paso 6:

    sudo mkdir /var/log/odoo

    sudo chown odoo:root /var/log/odoo


    Paso 7: Probar el servidor Odoo 


    Iniciamos el servidor Odoo:

    sudo /etc/init.d/odoo-server start

    Ahora abrimos un navegador (chrome recomendado) y en la barra de direcciones escribimos:

    http://localhost:8069

    Lo anterior suponiendo que está usando localhost, de lo contrario reemplace localhost por su dominio o IP.

    Una vez iniciado Odoo verá lo siguiente en pantalla:



    Detenemos el servidor Odoo:

    sudo /etc/init.d/odoo-server stop

    Finalmente automatizamos el lanzamiento de Odoo con el arranque del sistema:

    sudo update-rc.d odoo-server defaults

    ------------------------------------

    ¡Hasta la próxima ocasión!


    sábado, 26 de abril de 2014

    OpenERP - Localización funcional para Colombia - Recibos de Caja y Comprobantes de Egreso

    Gestión de recaudos y pagos en OpenERP

    ¡Vamos al grano!

    Para la gestión de tesorería OpenERP cuenta, entre otras, con las opciones del menú Contabilidad / Clientes / Pagos de cliente y Contabilidad / Proveedores / Pagos a proveedores, a pesar de ser dos menús independientes, ambos llevan a un mismo formulario que cambia parte de su estructura y contenido dependiendo si se trata de una entrada o de una salida de recursos.  Este formulario es denominado en términos técnicos account_voucher y lo podemos ubicar en el módulo que lleva ese mismo nombre.

    Al abrir el formulario account_voucher para ejecutar el proceso de recaudo de clientes o pago a proveedores disponemos de un campo denominado "Método de pago" que nos despliega una lista para seleccionar el que corresponda según se trate de un recaudo/pago en efectivo o a través de una cuenta bancaria.


    El "Método de pago", por su parte, no es otra cosa que un "Diario" de contabilidad de tipo "Efectivo" o "Banco y cheques".  Los Diarios de este tipo son mostrados tanto en la opción de recaudo de clientes como de pago a proveedores.


    Pues bien, para las prácticas contables de uso generalizado en Colombia lo anterior se convierte en un problema porque los "Diarios" tienen asociada una "Secuencia" y esto hace que se mezclen las numeraciones consecutivas de los recaudos con la de los pagos, numeración que aquí preferimos tener separada mediante el uso de dos documentos diferentes:  Recibos de caja para recaudos y Comprobantes de Egreso para pagos.

    Observen en las siguientes imágenes como la secuencia de los recaudos -imagen 1- es la misma de los pagos -imagen 2-.



    Segunda secuencia en Diario de contabilidad

    Pueden existir varias formas de atender el requerimiento descrito, esto es, separar la numeración -secuencia- de los recaudos y pagos.  En nuestro caso, el camino que hemos tomado es agregar un campo al formulario "Diario" para ingresar una segunda secuencia:


    El campo para agregar una segunda secuencia solo es visible en los Diarios de tipo "Efectivo" y "Banco y cheques".

    Asignación de secuencia según tipo de transacción

    Luego, hemos modificado el formulario account_voucher para que una vez se seleccione el "Método de pago" asigne la primera secuencia si se trata de un recaudo de clientes o la segunda secuencia si se trata de un pago a proveedores.  En términos técnicos identificamos la naturaleza de la transacción a través del campo "type", los recaudos corresponden a valores de "type" igual a "receipt", y los pagos a proveedores a valores de "type" igual a "payment".

    En las siguientes imágenes pueden observar como ahora tenemos dos numeraciones -secuencias- independientes, RC-000X para Recibos de caja y CE-000X para Comprobantes de egreso.



    Con esto damos un paso más en la localización funcional de OpenERP para Colombia.

    ¡Bienvenidos los comentarios!