Mostrando entradas con la etiqueta Odoo. Mostrar todas las entradas
Mostrando entradas con la etiqueta Odoo. Mostrar todas las entradas

lunes, 8 de febrero de 2016

Informes financieros bajo NIIF en Odoo v8

CONTEXTO

Como es bien sabido, Colombia se encuentra en pleno proceso de convergencia hacia normas internacionales de información financiera, más conocidas como NIIF o IFRS.  Una de las particularidades del proceso es que durante los primeros cuatro años de aplicación, las remisiones contenidas en las normas tributarias a las normas contables continuarán vigentes.  En virtud de lo anterior, la DIAN estableció como obligatorio la implementación de un sistema de registro de diferencias entre la contabilidad bajo NIIF y la contabilidad bajo el marco normativo anterior, esto es, decretos 2649 y 2650 de 1993.  Alternativamente, se puede dar cumplimiento a las exigencias fiscales mediante la implementación de un "Libro fiscal".

El tema ha resultado algo confuso entre los profesionales responsables de la contabilidad e información financiera de las entidades.  Igualmente, ha sido objeto de debate con posturas a favor y en contra de cada una de las alternativas propuestas por la DIAN.  A modo de ejemplo se pueden consultar estas dos publicaciones en línea:
  • Para darle cumplimiento a la Dian en el proceso de convergencia a NIIF por cual debemos optar: ¿por registros obligatorios o libro tributario?.  Parte I y Parte II
  • Guía del libro tributario y de la contabilidad IFRS en multinacionales.  Los casos típicos de la contabilidad multipropósito.  Versión 17
La segunda publicación, con la cual estoy completamente de acuerdo, hace mención de las prácticas inapropiadas seguidas por algunas casas de software contable en Colombia:
  • Repetición de todos los registros contables en dos bases de datos diferentes, una para NIIF y otra para marco normativo anterior.  
  • Implementación de dos planes de cuentas independientes, uno para NIIF y otra para marco normativo anterior.  
  • Diferenciación de registros bajo NIIF y bajo marco normativo anterior, mediante la implementación de una casilla de verificación en los documentos fuente.
En mi labor como consultor en implementación de sistemas de información en el ámbito empresarial he tenido que lidiar con aplicaciones que incorporan estos tres mecanismos al tiempo y he llegado a la conclusión de que es la peor forma de resolver el problema.

Las NIIF son un conjunto de normas, entendido el término norma como estándar, que se ocupan del reconocimiento, medición, presentación y revelación de información financiera.  Estudiarlas y comprenderlas requiere de sólidos conocimientos en finanzas, contabilidad y negocios, además de horas de análisis de las distintas opciones de aplicación disponibles, de acuerdo al sector o empresa de que se trate.

Lo importante aquí es tener claridad de que las NIIF no se ocupan de cómo elaborar registros contables, ni de definir planes de cuentas.  Su campo de cobertura está limitado a cómo se deben incorporar las distintas partidas en los estados financieros.  Contrario sensu, el marco normativo anterior si prescribe reglas a nivel de registro contable y dichas reglas son de aplicación obligatoria, mismas que encontramos en el decreto 2650 de 1993, más conocido como Plan Único de Cuentas.

Odoo 8 y la contabilidad multipropósito

Durante algún tiempo, debo reconocerlo, estuve igual de confundido sobre el tema que mis colegas responsables de la contabilidad e información financiera en las entidades, así como de los analistas funcionales de las casas de software del país.  Lograba comprender que se requería una contabilidad dual, así lo manifesté en varias ocasiones en mis publicaciones en la comunidad Odoo Colombia, pero no encontraba la forma de hacerlo en Odoo v8.  Afortunadamente, la segunda publicación citada me dio luces y al final logré la claridad conceptual requerida.

Resulta que Odoo v8 tiene incorporado un mecanismo para configurar los informes financieros a medida. La verdad es que antes no le había prestado mucha atención a esta funcionalidad, pero ahora "descubro" que es una de las formas de cumplir con la obligación de tener información financiera bajo NIIF y bajo marco normativo anterior sin necesidad de hacer desarrollo alguno.

Lo que permite el configurador de informes financieros en Odoo v8 es "mapear" los elementos que deseamos presentar en los estados financieros a partir de los tipos de cuentas o de las propias cuentas contables que utilizamos en los registros contables.  Así las cosas, resulta sencillo diseñar un Estado de Situación Financiera (NIIF) y un Balance General (marco normativo anterior) basados en la misma contabilidad, pero con resultados diferentes.

En la práctica vamos a enfrentar varios casos posibles: a) partidas que deben ser reconocidas en NIIF pero no en marco normativo anterior y visceversa, b) partidas que se miden de forma diferente en cada entorno, c) partidas que deben ser presentadas de una forma distinta y d) revelaciones que aplican en un entorno pero no en el otro.

En esta ocasión voy a dar un ejemplo de cómo presentar una misma partida cumpliendo con los dos marcos normativos:

El tratamiento de las inversiones en certificados de depósito a término bajo el marco normativo anterior señala que deben ser registradas en la cuenta 1225 y por lo tanto son presentadas en el Balance General en el grupo 12 - INVERSIONES.  Veamos este estado financiero para una empresa que tiene 250 millones en caja y 150 millones en CDT.  Para simplificar vamos a suponer que no tiene pasivos y por lo tanto su patrimonio es de 400 millones.



Ahora bien, dando aplicación a las NIIF en cuanto a la presentación del Estado de Situación Financiera, tenemos que las inversiones con un vencimiento próximo de al menos tres meses o menos desde la fecha de adquisición deben ser presentadas como efectivo y equivalentes de efectivo.

Supongamos entonces que el CDT tiene un vencimiento a 30 días.  El Estado de Situación financiera debería quedar así:





Conclusión:  Si un cliente le pregunta si Odoo v8 cumple con NIIF, la respuesta debe ser, POR SUPUESTO QUE SI.



jueves, 8 de enero de 2015

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


En una entrada anterior abordamos el tema de información exógena y propusimos una forma de atender la generación del Formato 1008 - Saldos de cuentas por cobrar a diciembre 31.  Vamos ahora a tratar el Formato 1009 - Saldos de cuentas por pagar a diciembre 31.  Acudimos de nuevo a la Resolución 000220 del 31 de octubre del 2014, pero esta vez al numeral 18.6 -pág 31-, en el que se establecen los criterios a cumplir en el reporte de los pasivos al 31 de diciembre del año gravable.  La estructura técnica la encontramos en el Anexo 25 Formato 1009v7.

Cuentas a conceptos


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

CONCEPTODESCRIPCIÓN
2201El valor del saldo de los pasivos con proveedores
2202El valor del saldo de los pasivos con compañías vinculadas accionistas y socios
2203El valor del saldo de las obligaciones financieras
2204El valor del saldo de los pasivos por impuestos, gravámenes y tasas
2205El valor del saldo de los pasivos laborales
2207El valor del saldo del pasivo determinado por el cálculo actuarial
2209El valor de los pasivos exclusivos de las compañías de seguros
2208El valor de los pasivos respaldados en documento de fecha cierta
2206El valor del saldo de los demás pasivos

Al igual que en el formato 1008, en el 1009 se puede obtener la información a través de la asociación de cuentas a conceptos.  Veamos la interfaz para este caso:


La descripción de los campos y las validaciones se pueden consultar en la publicación referida al Formato 1008.

No obstante, en este formato nos enfrentamos a un aspecto nuevo relacionado con el concepto 2204 - Impuestos, gravámenes y tasas.  Para éste, no es útil la información de las cuentas auxiliares sino la de las cuentas mayores.  Igualmente, no importan los saldos de los terceros sino que el reporte se hace a un solo tercero por cuenta.

Ilustremos la situación con un ejemplo:

La retención en la fuente la registramos en cuentas auxiliares como la 236505 - Salarios y pagos laborales, 236515 - Honorarios, etc.  En estas cuentas auxiliares capturamos los datos del tercero beneficiario del pago, por ejemplo 89111333 - Pedro Páramo.  Ahora bien, para efectos de la información exógena lo que debemos reportar es el saldo de la cuenta mayor 2365 - Retención en la fuente, y el tercero con quien tenemos la obligación es 800197268 - DIAN.

¿Cómo resolver esta situación en el proceso de generación automática de la información exógena en Odoo?

Ahí les dejo la inquietud.

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

No olviden visitar la lista de requerimientos y hacer sus contribuciones.

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

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!