jueves, 10 de octubre de 2013

Exportar movimientos contables en OpenERP 7.0


La situación


Los responsables de la gestión contable en las empresas tienen la necesidad de realizar pruebas técnicas sobre los registros para asegurar que los datos son consistentes y confiables.  Si bien una adecuada configuración de OpenERP puede garantizar la reducción del riesgo de error, el responsable de la contabilidad aún necesitará aplicar sus propias técnicas para verificar que todo esté funcionando en forma correcta. 

Las organizaciones de cierto tamaño cuentan con áreas responsables de control interno y en muchos casos, además, se contratan firmas de auditoría o profesionales independientes ajenos a la organización para que ejecuten labores de auditoría financiera externa.  Este tipo de usuarios, al igual que el área contable, necesitan acceder a los datos contables para aplicar sus propias pruebas de auditoría financiera.  

Si bien OpenERP tiene la capacidad de exportar registros detallados de todas las transacciones, no solo movimientos contables, y a pesar de la flexibilidad que ofrece para seleccionar los datos (campos) a exportar, así como los formatos (csv o xls), cuando el volumen de datos a exportar es muy grande el proceso se hace extremadamente lento, llegando incluso a situaciones en las que esta labor es realmente imposible de ejecutar desde la interfaz de usuario. 

Para atender esa necesidad podemos acudir a una extensión comunitaria del módulo Contabilidad y Finanzas desarrollada por la empresa Camptocamp denominada "Account Export CSV"     


Extensión Account Export CSV


La extensión "Account Export CSV" puede ser descargada desde la sección Apps del sitio oficial de OpenERP:  


Después de instalada podremos generar nuestro archivo a exportar desde el menú:

Contabilidad / Informes / Accounting CSV Export
 
Seleccionamos el año fiscal y después los períodos y los diarios que correspondan según nuestra necesidad concreta:


Contamos con tres opciones de reporte:
  1. Balance de comprobación - Trial Balance
  2. Balance analítico (con cuentas) - Analytic Balance (with accounts)
  3. Entradas de los Diarios - Journal Entries
Damos clic en el tipo de reporte que deseamos y de forma muy eficiente es generado el archivo csv solicitado, damos clic en descargar y listo, ya podemos continuar con nuestro trabajo.

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

Esta extensión me ha resultado muy útil y hasta ahora no he tenido problemas con su funcionamiento ni he detectado efectos no deseados en otros componentes del módulo Contabilidad y Finanzas.

De todas formas siempre es recomendable que antes de usar este tipo de extensiones comunitarias en ambientes de producción, revise primero su funcionamiento en entornos de prueba.

Sigan ese consejo, ya he tenido malas experiencias con extensiones comunitarias, no todas son confiables. 

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

miércoles, 25 de septiembre de 2013

¿Para qué sirven los "Códigos de impuestos" en OpenERP 7.0?

Los códigos de impuestos en OpenERP 7.0 permiten definir la estructura de cada uno de los informes a ser utilizados para diligenciar los formularios de declaración de impuestos con  destino a las autoridades tributarias.  Como la regulación sobre esta materia es diferente para cada país, los datos de configuración de códigos de impuestos estarán en los proyectos de localización, y si no, será responsabilidad del equipo de implementación realizarla antes de la puesta en producción.

Para explicar cómo realizar la configuración de los códigos de impuestos vamos a describir un caso práctico real.


Declaración del Impuesto sobre las Ventas - IVA


En Colombia las actividades de comercialización de productos están sometidas al impuesto sobre las ventas - IVA, tanto en operaciones de compra como de venta, existen diferentes tarifas, hay productos exentos y excluidos, hay reglas específicas para operaciones de intercambio internacional y finalmente, algunos tratamientos especiales según el tipo de operación o el tipo de empresa que la está ejecutando.

La forma cómo se informa a la autoridad de impuestos el valor del impuesto a pagar es mediante la presentación bimestral del formulario "Declaración del Impuesto sobre las Ventas - IVA".

Este es el formulario vigente para el año gravable 2013:



Configuración de "Códigos de impuestos"


Para acceder al menú de configuración de códigos de impuestos vamos a Contabilidad / Configuración / Impuestos / Códigos de impuestos.

El primer paso es crear un código de impuesto para identificar cada informe, en el ejemplo el informe se llamará "Declaración del Impuesto sobre las Ventas - IVA" y le asignaremos como código el mismo del formulario oficial: 300.

Nótese que el campo "Código padre" está vacío, eso significa que éste código es el del nivel superior en la estructura jerárquica del informe.

El segundo paso es crear el siguiente nivel jerárquico, en este caso crearemos dos códigos, el primero para identificar las secciones destinadas a informar los valores de las operaciones objeto de impuesto, es decir, el valor de las ventas y de las compras; y el segundo código lo usaremos para calcular el saldo a pagar por concepto de IVA (puede ser también un saldo a favor):


Nótese que hemos colocado en "Código" los números 78-79, estos coinciden con los números de los renglones del formulario en el que se diligencia el saldo a pagar (renglón 78) o el saldo a favor (renglón 79).

De aquí en adelante lo que nos queda es seguir creando los códigos de impuestos en tantos niveles jerárquicos como sean necesarios, en la tabla siguiente encontrarán el listado requerido para una configuración básica:

Nombre código de impuesto Código Código padre
Total ingresos netos recibidos durante el período 41 Bases de Impuestos
Total compras netas realizadas durante el período 55 Bases de Impuestos
Total impuesto generado por operaciones gravadas 63 78-79 - Saldo a pagar o a favor del período fiscal
Total impuestos descontables 77 78-79 - Saldo a pagar o a favor del período fiscal
Ingresos por operaciones gravadas a la tarifa general 28 41 - Total ingresos netos recibidos durante el período
Ingresos por operaciones excluidas 37 41 - Total ingresos netos recibidos durante el período
Devoluciones en ventas anuladas, rescindidas o resueltas 40 41 - Total ingresos netos recibidos durante el período
Compras de bienes gravados a la tarifa general (Nacionales) 43 55 - Total compras netas realizadas durante el período
Compras de bienes y servicios no gravados 52 55 - Total compras netas realizadas durante el período
Devoluciones en compras anuladas, rescindidas o resueltas 54 55 - Total compras netas realizadas durante el período
Impuesto generado a la tarifa general 57 63 - Total impuesto generado por operaciones gravadas
IVA recuperado en devoluciones en compras anuladas... 62 63 - Total impuesto generado por operaciones gravadas
Impuesto descontable por compra de bienes a la tarifa general 68 77 - Total impuestos descontables
IVA resultante por devoluciones en ventas anuladas... 74 77 - Total impuestos descontables


Configuración de "Impuestos"


Ahora que ya tenemos nuestra estructura de la declaración pasamos a usarla en la configuración de los impuestos, para ello vamos a Contabilidad / Configuración / Impuestos / Impuestos.

Creamos cada uno de los impuestos que se necesiten, a modo de ejemplo veamos el IVA generado en operaciones de venta a la tarifa general del 16%:


En el formulario de creación del impuesto nos aseguramos de colocar en el campo "Código base cuenta" el número del renglón de la declaración en el que se reportará el valor de la operación que genera el impuesto y en el campo "Código impuesto contable" el número del renglón de la declaración en el que se reportará el valor del impuesto generado.

Suponiendo que realizamos una venta de $100 con IVA a la tarifa general del 16%, obtendremos en "Código base cuenta" : $100 y en "Código impuesto contable" : $16.


Generar el "Informe impuestos"


Ya está todo listo, así que una vez terminado el periodo bimestral podremos generar el informe y basarnos en él para diligenciar el formulario oficial "Declaración del Impuesto sobre las Ventas - IVA", para ello vamos a Contabilidad / Informe / Impuestos / Informe impuestos, le indicamos los periodos que deseamos y listo:



Aquí pueden ver el resultado:


----

¡No olviden difundir y dejar sus comentarios!


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.


miércoles, 12 de junio de 2013

OpenERP - Extensión "Cash and Bank Transfers"


La anterior entrada de este blog la dedicamos a explicar la forma como está concebida la gestión de consignaciones, retiros y traslados de fondos en el módulo Contabilidad y Finanzas de OpenERP [1], dicha entrada recibió comentarios muy valiosos a través de G+, google-groups y linkedin, agradezco por este medio a todos los que decidieron compartir parte de sus conocimientos y con argumentos plantearon sus puntos de vista acerca del tema.

[1]  http://openerp-co.blogspot.com/2013/05/gestion-de-tesoreria-en-openerp-70.html

Hoy vamos a dedicar las líneas de esta entrada a una extensión no oficial del módulo Contabilidad y finanzas de OpenERP que propone una forma simplificada para realizar consignaciones, retiros y traslados de fondos, se trata de "account_transfer - Cash and Bank Transfers" [2], un trabajo liderado por la empresa Peruana Cubic ERP.


Antes de continuar debo advertir que, tal como se puede observar en el sitio donde está publicada, para OpenERP en su versión 7.0 la extensión aún está en desarrollo (trunk), no obstante, puede ser descargada y usada en entornos de prueba para conocer su funcionamiento.

Una vez descargada la extensión y colocada la carpeta "account_transfer" en el directorio "addons" de nuestro servidor OpenERP y después de ejecutar la opción "Actualizar la lista de módulos", tendremos disponible para instalación la extensión "Cash and Bank Transfers":           



Instalada la extensión dispondremos de un nuevo menú en el módulo Contabilidad en la sección "Banco y caja" denominado "Transferencias de efectivo y...".  

Antes de usar el formulario debemos configurar los Diarios de "Efectivo" y "Bancos" colocando un nuevo parámetro, una cuenta contable de tránsito "Account Transit".  Puede ser usada la misma cuenta que hayamos definido para el campo "Cuenta de transferencias internas" (ver entrada anterior).



Desde el menú "Transferencias de efectivo y..." abrimos el formulario, su llenado es muy simple, se indica la Fecha, el Diario origen, el Valor y el Diario destino.  En nuestro ejemplo estamos haciendo una consignación, así que el Diario origen es "Efectivo" y el Diario destino es un "Banco". 



Después de confirmar la transacción se hará visible la pestaña "Payments" en la que se mostrarán en modo lista los Diarios afectados:



Igualmente, si vamos al menú lateral "Asientos contables" encontraremos dos asientos para esta transacción, uno en el Diario "Efectivo" y otro en el Diario "Banco", como podrán ver, la cuenta contable de tránsito "Account Transit" es la que permite generar el registro contable correcto:




Esta extensión puede resultar muy útil en pequeñas y medianas empresas en las que la gestión de tesorería (Cajas y Bancos) es realizada por una sola área o incluso una sola persona.   

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

Es tradición contable en Colombia utilizar comprobantes de contabilidad (Diarios) por tipo de documento, así que es posible que el responsable de la gestión contable en empresas donde se vaya a implementar OpenERP prefiera usar un Diario independiente para las Consignaciones, Traslados y Retiros, incluso, Diarios separados para cada uno de estos tipos de documentos.  Tal como está concebido actualmente el proceso en la distribución oficial de OpenERP y en la extensión descrita en esta entrada, eso solo se puede realizar a través de registros directos usando la opción "Asientos contables".

Se me ocurre que si la extensión "Cash and Bank Transfers" en lugar de usar la cuenta de tránsito "Account Transit" usa como parámetros las "Cuentas deudora (o acreedora) por defecto" de los Diarios "Origen" y "Destino", podría perfectamente realizar el registro contable en un nuevo Diario que podríamos llamar Diario de "Transferencias internas".  Ahí les dejo la inquietud.



domingo, 19 de mayo de 2013

Gestión de "Tesorería" en OpenERP 7.0 - Traslados, Consignaciones y Retiros

La situación:

En la gestión de tesorería de las empresas una de las transacciones habituales es el movimiento de fondos desde un banco o caja a otro banco o caja de la misma compañía.

Según el origen y destino de los fondos podemos clasificar estas transacciones en tres tipos diferentes:

Traslados:  Los traslados son movimiento de fondos de un Banco A a un Banco B de la misma empresa, así como los movimientos de una Caja A a una Caja B.

Cuando se realiza un traslado el asiento contable es cómo el siguiente:

Cuenta Descripción Débito Crédito
11100501 Barco Ganadero cta 123456 1.250.000
11100502 Barco de Bogotá cta 789123 1.250.000

Si es entre cajas:

Cuenta Descripción Débito Crédito
11050501 Caja principal 1.000.000
11050502 Caja bodega 1.000.000

Consignaciones:  Las consignaciones son depósitos de fondos desde una Caja X a un Banco X de la misma empresa.

Veamos un ejemplo de asiento contable:

Cuenta Descripción Débito Crédito
11100501 Barco Ganadero cta 123456 2.000.000
11050502 Caja bodega 2.000.000

Retiros:  Corresponden a retiros de fondos en efectivo desde un Banco X a una Caja X de la misma empresa.

El asiento contable en este caso podría ser como el siguiente:

Cuenta Descripción Débito Crédito
11050501 Caja principal 1.800.000
11100501 Barco Ganadero cta 123456 1.800.000

¿Cómo gestionar Traslados, Consignaciones y Retiros en OpenERP 7.0?

En OpenERP la gestión de tesorería se realiza en el módulo "Contabilidad" a través de las opciones "Extractos bancarios" y "Registros de caja" del menú "Banco y caja".

En el diseño de OpenERP 7.0 no está contemplada la posibilidad de realizar Traslados, Consignaciones y Retiros de forma directa.  En su lugar, tiene previsto el uso de una "Cuenta de transferencias internas" como mecanismo indirecto para lograr el asiento contable correcto.

Esto es así, porque OpenERP 7.0 busca que las transacciones de cada Banco o Caja sean asentadas en su propio "Diario".  A modo de ejemplo, para realizar una Consignación primero se ejecutará la opción "Sacar dinero" del formulario "Registros de caja" y luego se ejecutará la opción "Poner dinero" del formulario "Extractos bancarios".

Un ejemplo completo:

De acuerdo a lo anterior, lo primero que debemos hacer es crear una cuenta contable que nos sirva de intermediaria y colocarla en la configuración de los "Diarios" de "Efectivo" y "Bancos" en el campo "Cuenta de transferencias internas".


El ejemplo que vamos a realizar corresponde a una consignación, así que lo primero es sacar el dinero de la Caja, entonces, en un "Registro de caja" vamos a ejecutar la opción "Sacar dinero".


OpenERP nos habilitará una ventana emergente para ingresar el concepto y la cantidad de dinero a sacar.


Una vez que ejecutemos la opción "Cierre de caja" tendremos disponible una nueva pestaña en el formulario con el "Asiento contable".


Como podrán observar, tenemos un registro débito a la "Cuenta de transferencias internas".

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

Ahora creamos un extracto bancario y ejecutamos la opción "Poner dinero".


OpenERP nos habilitará una ventana emergente para ingresar el concepto y la cantidad de dinero a poner.



Una vez que ejecutemos la opción "Confirmar" tendremos disponible un botón en el formulario para acceder al "Asiento contable".


Al hacer clic sobre el botón tendremos el "Asiento contable".



Como podrán observar, tenemos un registro crédito a la "Cuenta de transferencias internas".

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

En una próxima entrada les daré mi opinión profesional acerca de este tema, por ahora, los invito a que dejen sus comentario.


jueves, 11 de abril de 2013

Adivina adivinador, los módulos de OpenERP ¿Cuántos son?

Tal vez por Contador Público hago este tipo de cuentas, o a lo mejor por Auditor me tomo la tarea de verificar afirmaciones de otros.

El caso es que en la publicidad de OpenERP siempre se encuentra una cifra diferente sobre los módulos que están disponibles para sus usuarios, en la última presentación que conozco [1] dicen que OpenERP dispone de una cifra superior a 1.500 módulos.  ¿Será eso cierto?.

[1] http://www.slideshare.net/openobject/people-at-openerp-ephec-brussels-march-2013

Algunos repetirán al unísono que sí, que la comunidad es muy activa y que efectivamente son tantos los módulos disponibles que es difícil establecer una cifra exacta.

Yo prefiero darle a mis clientes datos más precisos, qué tal que me encuentre uno bien excéntrico que me pida que le instale los 1.500 módulos, de seguro estaría en serios aprietos.

Para hacer la cuenta de los módulos disponibles de OpenERP apliqué varios filtros, en primer lugar consideré solo los módulos disponibles en la distribución oficial.  ¿Por qué excluí los módulos comunitarios?, simplemente porque no han sido avalados oficialmente.  Es posible que muchos de ellos sean de muy buena calidad, pero también es cierto que son muchos los que simplemente no aportan valor a OpenERP.

Aplicado el filtro anterior me queda una cifra de 204 módulos.  ¿Es esa la cifra real?.  Yo creo que no.

Y es que quien haya trabajado con OpenERP o al menos lo haya explorado un poco, sabrá que hay unos módulos principales y que los demás modulos disponibles en realidad son "extensiones" de aquellos que sirven para agregarles ciertas funcionalidades o modificarlos para adaptarlos a una necesidad concreta.

Hecha mi propia clasificación llego a la conclusión de que los módulos de OpenERP no son ni 1.500, ni 204, sino 15 o 18, depende como se interprete el módulo "otros".  Para llegar a esa cifra separé los módulos principales y para cada uno de ellos identifiqué sus extensiones, en algunos casos tuve que elegir a cuál módulo principal asociar una que otra extensión porque se trataba de extensiones que justamente "conectan" dos módulos principales.

Aquí les dejo el resultado de este ejercicio en una imagen, los recuadros de colores son los módulos principales y las cifras a su derecha son la cantidad de extensiones que tienen asociadas:


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


martes, 2 de abril de 2013

OpenERP - Cambiar "Contraseña maestra"

En la entrada anterior explicamos los pasos necesarios para instalar OpenERP 7.0 en Ubuntu 12.04 LTS, si todo ha salido bien ya estamos listos para comenzar a explorar los aspectos técnicos y funcionales, eso nos tomará un tiempo, tendremos temas simples y otros realmente complejos, así que lo mejor es comenzar de una vez.

Si aún no has instalado OpenERP puedes seguir la guía: "Instalar OpenERP 7.0 en Ubuntu 12.04".

Cuando ingresamos por primera vez a OpenERP recibimos una solicitud de creación de base de datos, cada base de datos es equivalente a una "Compañía" o "Empresa", podemos crear tantas empresas (bases de datos) como queramos.



El primer campo - "Contraseña maestra" - aparece diligenciado con un valor por defecto, si estamos en un entorno de prueba a lo mejor ni nos damos cuenta de que ese campo está ahí, pero después cuando deseemos eliminar una base de datos nos vamos a preguntar: ¿cuál es la "bendita" contraseña?. No hay de que  preocuparse, la podemos adivinar, la contraseña es: admin.

El caso es que el cerebro a veces nos hace malas jugadas, nos acostumbramos a crear y borrar bases de datos con la contraseña admin y cuando pasamos a una situación de instalación de OpenERP en un entorno real - en producción - nos surge la necesidad de proteger el sistema con una contraseña más segura, y vaya, ¡no tenemos ni idea de cómo cambiar la "bendita" contraseña!.

Y digo que es culpa del cerebro porque la fuerza de la costumbre lo vence y hace que dejemos de ver el menú lateral de la izquierda, justo en la última opción tenemos "Contraseña", es por ahí que se cambia la "bendita" Contraseña maestra.



Ahora bien, para que el cerebro no nos vuelva a hacer malas jugadas, lo mejor es seguir las reglas de los planes de seguridad informática, estos a lo mejor nos  dirán que debemos escribir la contraseña en un papel, depositar el papel en un sobre opaco, sellar el sobre y entregarlo formalmente a la persona responsable de la custodia de valores de la empresa para que lo almacene en la caja fuerte o en el mecanismo alterno que tengan dispuesto para estos menesteres.

Una recomendación final, no importa cuanto nos torturen, no debemos revelar a nadie la "bendita" Contraseña maestra.

Corolario: Tampoco podemos confiar en mujeres hermosas que traten de seducirnos, lo que ellas buscan es la "bendita" Contraseña maestra.  ¿No les ha pasado ya antes?.

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

Posdata: Si tuviste la paciencia de leer esta entrada voy a pedirte un esfuerzo adicional, que respondas la encuesta de la barra lateral derecha: 

¿TIENES EXPERIENCIA EN LA IMPLEMENTACIÓN O USO DE SISTEMAS ERP?. ¿CON CUÁLES?


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

sábado, 30 de marzo de 2013

Instalar OpenERP 7.0 en Ubuntu 12.04

OpenERP es un sistema de gestión de información empresarial integral, modular y adaptable, distribuido como software libre bajo licencia AGPL.  Ya dedicamos dos publicaciones [1] - [2] a la definición de OpenERP, es el momento de entrar en acción, el primer paso que vamos a dar es la instalación de la última versión estable, la 7.0, en el sistema operativo Ubuntu 12.04 LTS.

[1] (re) Definiendo el concepto ERP 
[2] OpenERP es Software Libre no solo Open Source

Esta entrada está basada en la publicación "How to install OpenERP 7.0 on Ubuntu 12.04 LTS" del blog "The Open Sourcerer" la cual está amparado 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 OpenERP


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 OpenERP, para ello le asignamos el directorio en el que instalaremos luego OpenERP, en este caso /opt/openerp, si no existe el directorio, este será creado automáticamente.  Si decide 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/openerp --group openerp

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 OpenERP, tendrá permisos para crear y borrar bases de datos.  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 openerp
Enter password for new role: ********
Enter it again: ********


Finalmente salimos del usuario postgres:

exit

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


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


Paso 4: Instalar el servidor OpenERP 


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

https://www.openerp.com/es/pricing

Seleccionamos el enlace que suministra las fuentes, Sources:


Si aún no es un usuario registrado deberá diligenciar el siguiente formulario para poder acceder a la descarga:


Si todo ha salido bien, se descargará un archivo llamado openerp-7.0-latest.tar.gz

Para instalarlo vamos primero al directorio que creamos en el Paso 1:

cd /opt/openerp

Extraemos los archivos (descomprimimos):

sudo tar xvf ~/openerp-7.0-latest.tar.gz

Si la carpeta queda con un nombre como openerp-7.0-20130117-134423 se lo cambiamos a server de tal manera que la ruta del servidor quede así: /opt/openerp/server/.

Asignamos permisos para el directorio, al usuario y grupo creados en el Paso 1:

sudo chown -R openerp: *

Paso 5: Configurar el servidor OpenERP 


Copiamos el archivo openerp-server.conf que se encuentra en /opt/openerp/server/install a la carpeta /etc/ y le asignamos los permisos adecuados:

sudo cp /opt/openerp/server/install/openerp-server.conf /etc/
sudo chown openerp: /etc/openerp-server.conf
sudo chmod 640 /etc/openerp-server.conf


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

Modificamos el archivo openerp-server.conf para suministrarle la contraseña de la base de datos:

sudo gedit /etc/openerp-server.conf

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

Adicionamos una línea en el archivo openerp-server.conf para indicarle a OpenERP donde escribir el archivo del log:

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

La configuración está lista, es hora de probar si todo anda bien:

sudo su - openerp -s /bin/bash
/opt/openerp/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 OpenERP presionamos simultáneamente las teclas CTRL y C.

Para salir del usuario openerp escribimos exit.

Paso 6: Lanzar OpenERP al arranque del sistema 


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

Para ello creamos un archivo con nombre openerp-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/openerp-server
sudo chown root: /etc/init.d/openerp-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/openerp
sudo chown openerp:root /var/log/openerp


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

sudo update-rc.d openerp-server defaults


Paso 7: Probar el servidor OpenERP 


Iniciamos el servidor OpenERP:

sudo /etc/init.d/openerp-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 OpenERP verá lo siguiente en pantalla:


Detenemos el servidor OpenERP:

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

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

Espero les sea útil, hasta la próxima.


lunes, 25 de marzo de 2013

OpenERP es Software Libre no solo Open Source

Introducción


En la primera entrada de este blog nos propusimos definir OpenERP y para ello dividimos el término en sus dos componentes Open y ERP, dedicamos luego unas líneas a profundizar en el segundo término dando como resultado una propuesta concreta de definición:

ERP - Enterprise Resource Planning:

Sistema de gestión de información empresarial que tiene como atributos principales la Integralidad (Capacidad de gestionar la totalidad de requerimientos transaccionales de una empresa), la Modularidad (la gestión de los requerimientos transaccionales es realizada a través de subsistemas integrables - módulos -, ordenados de forma lógica y armónica según criterios funcionales) y la Adaptabilidad (Capacidad de ajustarse a las necesidades particulares del modelo de negocio de la empresa).

Ahora es el turno de tratar de comprender el significado del término Open en el nombre OpenERP, vamos a ver si lo logramos.

Open - un término que confunde 

Para quienes llevamos algún tiempo en el "mundo" del software libre es apenas lógico y natural que asociemos el término Open con el software open source o de código abierto.  Pareciera entonces que la respuesta a la pregunta que motiva esta entrada es simple:  OpenERP es software open source.

Pero nuestro estilo no es llegar a conclusiones a la ligera sino que asumimos la tarea de indagar un poco más para confirmar si esa primera impresión es cierta o no, acudimos por lo tanto al sitio oficial de OpenERP y nos encontramos con una afirmación que podríamos calificar de contradictoria:
"Codigo abierto: OpenERP esta dedicado al modelo de negocio de codigo abierto. El software está publicado bajo la licencia AGPL".

¿Por qué contradictoria?

Sencillo, la licencia AGPL es una licencia de software libre y aunque esta tenga cosas en común con las licencias open source, no son iguales, de hecho hay ciertos puntos que son claramente incompatibles.

No es el objetivo de esta entrada explicar en detalle las diferencias entre las licencias de software open source y las licencias de software libre, esa tarea se la dejamos al lector, si lo desean pueden consultar las siguientes fuentes:

The Open Source Definition
Por qué el código abierto pierde el punto de vista del software libre

OpenERP es software libre


No debe haber duda al respecto, en la página de descargas de OpenERP se lee:
"OpenERP y todos sus módulos son completamente código libre, publicado bajo licencia AGPL"
La AGPL es una de las licencias de software libre publicadas por la Free Software Foundation y su propósito principal es garantizar la libertad de los usuarios y asegurar que el software siga siendo software libre.


Voy a partir de una hipótesis que puede ser falsa, "pocos usuarios se ocupan de revisar el contenido de las licencias de software, incluyendo usuarios que desarrollan software libre".  Entonces voy a recordar las libertades esenciales promovidas por la Free Software Foundation en sus licencias:

  • La libertad de ejecutar el programa para cualquier propósito (Libertad 0)
  • La libertad de estudiar cómo funciona el programa, y cambiarlo para que haga lo que usted quiera (Libertad 1).  El acceso al código fuente es una condición necesaria para ello.
  • La libertad de redistribuir copias para ayudar a su prójimo (Libertad 2).
  • La libertad de distribuir copias de sus versiones modificadas a terceros (Libertad 3).  Esto le permite ofrecer a toda la comunidad la oportunidad de beneficiarse de las modificaciones.  El acceso al código fuente es una condición necesaria para ello.
Ahora bien, la AGPL es una licencia especial, fue diseñada para garantizar las libertades a los usuarios que acceden a software libre a través de una red:
Licencia Pública General Affero de GNU (AGPL) versión 3:
Esta es una licencia de software libre con copyleft. Sus términos son en la práctica los mismos de la GPLv3, con un párrafo adicional en la sección 13 que permite a los usuarios que interactúan con el software bajo esta licencia en una red, recibir la fuente de tal software.
En vista de que la más reciente apuesta de OpenERP es el modelo de software como servicio SaaS, esta licencia es la adecuada.

Software libre vs Open source 
- Una "sutil" deiferencia - 
No quiero cerrar esta entrada sin mencionar una de las diferencias entre las licencias de software open source y las licencias de software libre.  

Unas líneas atrás dije que las licencias promovidas por la FSF buscan asegurar que el software siga siendo libre, ¿eso que significa?, nada más y nada menos que las versiones modificadas del software deben ser distribuidas bajo los mismos términos de la licencia original, en el caso de OpenERP, la AGPL.  La única excepción a esta regla es distribuir las modificaciones con una licencia compatible, y eso nos lleva necesariamente a otra licencia de software libre, la GPL.

En las licencias de software open source esta condición no existe, es más, expresamente promueven lo opuesto:
La licencia no debe ir en contra de otro software. La licencia no debe restringir otro software que se distribuya con el mismo. Por ejemplo, la licencia no debe indicar que todos los programas distribuidos conjuntamente con el deben ser opensource.
Es por eso que en el mundo del open source es habitual encontrar dos versiones del mismo producto, la Comunitaria y la Enterprise (Premium, Gold, etc), normalmente la versión comunitaria tiene limitaciones funcionales o legales y es usada (en muchos casos) solo como instrumento de marketing (señuelo).

En virtud de la licencia AGPL, con OpenERP no puede suceder tal cosa.

-----------------------
Nota:  Hay que aclarar que OpenERP no ha tenido siempre la misma licencia, en versiones anteriores el cliente web tenía una licencia diferente del resto del software.  También hay que aclarar que el titular de los derechos de autor no está obligado a sacar futuras versiones con la misma licencia.  Por lo pronto, estamos tranquilos por que la versión 7.0 de OpenERP es realmente software libre, así ellos mismos se publiciten como software open source.
-----------------------

sábado, 23 de marzo de 2013

(re) Definiendo el concepto ERP

Motivación

Inauguramos hoy este blog dedicado a la publicación de temas sobre OpenERP y particularmente sobre su localización para Colombia.

Antes de entrar a tocar temas técnicos y/o funcionales es necesario comenzar con una definición de OpenERP, pero contrario a lo que se podría pensar la tarea no es simple, básicamente porque - a nuestro juicio - no hay un consenso sobre el significado y alcance de las dos siglas que componen el nombre, Open y ERP.

Sin más preámbulos, comencemos con la segunda sigla: ERP.

¿Que es un ERP?

Simple, ERP es la sigla de "Enterprise Resource Planning", y si lo prefiere en español, "Planificador de Recursos Empresariales".

¿Eso te dice algo?, en realidad creo que no mucho.

Entonces acudamos a la enciclopedia para ver si tenemos mejor suerte:

Definición de ERP en Wikipedia.

¿Quedó claro?, yo creo que no.

Desafortunadamente la definición de ERP en Wikipedia es ambigua, imprecisa, contradictoria, confusa y, por qué no, obsoleta.  Por eso Wikipedia no es la mejor fuente de información en este caso.

¿Y si buscamos otras fuentes en Internet?.

Vamos a obtener un resultado similar, los invito a que hagan el ejercicio.

¿Y entonces?.

No queda otra opción, tratar de construir un definición a partir de las fuentes consultadas y, sobre todo, de la concepción personal (prejuicios) sobre el asunto.  Para no convertirnos en otra "mala" definición, guardamos la esperanza de que quienes lean este artículo nos ayuden con sus comentarios, es así como aspiramos (re) definir el concepto ERP.

Señalemos en primer lugar que es insuficiente definir un ERP a partir de lo que tiene, decir que es un sistema que integra la gestión de producción, logística. distribución, marketing, ventas, contabilidad, etc; es como decir que el ser humano es un conjunto integrado de huesos, músculos, órganos, etc.  Esta es tal vez la definición más usada en labores de marketing de los distintos ERP disponibles en el mercado y es también, la principal razón de confusión entre las definiciones de ERP y de SGE - Sistemas de Gestión Empresarial, y claro, esto es aprovechado por las empresas dedicadas a comercializar SGE, las cuales  cambian solamente el nombre de sus productos y los venden como si se trataran de verdaderos ERP, hay muchos ejemplos de esta práctica.

En segundo lugar, también es insuficiente definir un ERP a partir de su origen y evolución, aquí diríamos que primero surgieron los MRPMaterial Requerement Planing, que luego evolucionaron hasta convertirse en MRP IIManufacturing Resource Planing, para finalmente madurar y consolidarse en lo que actualmente conocemos como ERPEnterprise Resource Planning.  Tal vez esta definición sea un poco más acertada en términos técnicos, pero es difícil de digerir, obliga a entender el contexto en el que surgieron cada una de las variantes y a comprender el alcance de cada una de ellas.  Hecho ese ejercicio se tendrá claridad de que si estamos frente a una evolución de un sistema, no podría llamarse ERP a aquel que no tenga los subsistemas MRP y MRP II, y comprendido eso, ya comenzaremos a diferenciar los SGR de los ERP.

Podríamos también intentar acercarnos a la definición de ERP a partir de sus objetivos y características técnicas, pero en últimas caeríamos en el mismo error, no estaríamos delimitando con precisión lo que es un ERP porque esos objetivos y características las pueden tener otros tipos de soluciones.

Así que optaremos por construir una definición basada en los atributos de un ERP, creemos que esta es la que recoge la verdadera esencia de este tipo de soluciones y además, es la de más fácil comprensión.

ERP - Enterprise Resource Planning:

Sistema de gestión de información empresarial que tiene como atributos principales la Integralidad (Capacidad de gestionar la totalidad de requerimientos transaccionales de una empresa), la Modularidad (la gestión de los requerimientos transaccionales es realizada a través de subsistemas integrables - módulos -, ordenados de forma lógica y armónica según criterios funcionales) y la Adaptabilidad (Capacidad de ajustarse a las necesidades particulares del modelo de negocio de la empresa).

La tesis implícita en la definición es que si un sistema de gestión empresarial cumple los tres atributos, es un ERP.

Hagamos ahora algunas precisiones tomando fragmentos de la definición:

Sistema de gestión de información empresarial: Limita el ámbito de aplicación del sistema, indica que se trata de una aplicación dirigida a atender las necesidades de las empresas, obviamente en un sentido amplio.

Requerimientos transaccionales: Este es un punto importante, la naturaleza de un ERP es gestionar adecuadamente la operación cotidiana de una empresa, esa operación puede ser representada en flujos de procesos y documentos asociados a los mismos.  A modo de ejemplo, una empresa cuenta con flujos de procesos para ventas, compras, producción, marketing, etc;  en cada uno de ellos genera diversos documentos como cotizaciones, pedidos, órdenes de producción, etc.  Visto desde otra perspectiva, un ERP no necesariamente debe contar las características de un sistema de inteligencia de negocios, aunque hay que decirlo, actualmente varios ya la ofrecen.

Gestionar la totalidad de requerimientos:  Cuando hablamos de cobertura total lo hacemos en un contexto específico, el actual.  Hoy en día los requerimientos transaccionales no pueden ser vistos solo considerando las necesidades al interior de la empresa, es imprescindible incorporar a todas las partes relacionadas.  Como consecuencia de lo anterior, los módulos "utilitarios" son igual de importantes a los módulos tradicionales, esto es, el ERP debe estar en capacidad de integrarse de forma natural con proveedores, clientes y empleados;   debe estar vinculado a las plataformas de comercio electrónico de la empresa (tiendas on-line, marketplace, etc); y debe permitir compartir recursos (documentos compartidos, redes sociales, calendarios, correos electrónicos, etc.).

Subsistemas integrables - módulos -:  Un ERP debe estar diseñado como el tradicional juego "armotodo", eso significa que el sistema puede crecer o variar simplemente acoplando o retirando piezas.  Debe haber piezas disponibles de diferentes "formas", "tamaños" y "colores", solo así el sistema podrá ser robusto y flexible a la vez.

Ajustarse a las necesidades particulares del modelo de negocio:  Este es a mi juicio el atributo diferenciador más destacado de un ERP, es el sistema el que se adapta al modelo de negocio de la empresa y no al revés. Claro está, el ERP en su forma estándar debe ofrecer un diseño ajustado a las "mejores prácticas" de cada uno de los procesos de la empresa, pero no todas las empresas funcionan con "mejores prácticas" en todas sus áreas.

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

Ahora es su turno, ayúdenos a (re) definir el concepto ERP.