logo

Nueva web FactorLibre

¡Hola! Ha llegado el momento de inaugurar nuestro blog y nuestra nueva web, en la cual queremos mostraros los servicios que prestamos como consultora tecnológica especializada en soluciones de código abierto.

Detrás de Factor Libre estamos un equipo plenamente formado y con mucha experiencia en las tecnologías libres con las que actualmente trabajamos: OpenERP, Spree y Ruby On Rails. Actualmente tenemos oficinas en Madrid y en Cantabria, pero contamos con colaboradores en varias partes de España para estar lo más cercanos a nuestros clientes. Por lo que, estés donde estés, cuéntanos tu proyecto que seguro que podemos ayudar de alguna manera. 😉

A lo largo de las diferentes entradas de este blog, os informaremos por un lado de las últimas novedades de OpenERP, Spree y Ruby on Rails, además de contaros nuestros casos de éxito y las noticias corporativas internas.

Muchas gracias por estar ahí, para cualquier cosa que necesitéis estamos a «tiro de click» en nuestro formulario de contacto. ¡Arrancamos!

Read more http://factorlibre.com/blog/posts/nueva-web-factorlibre

Leer más

Nace Factor Libre

¡Hola! A través de este post de bienvenida, damos por inaugurada nuestra flamante página web y comenzamos a ofrecer nuestros servicios al público interesado. ;)

Detrás de Factor Libre, estamos un equipo plenamente formado y con mucha experiencia en las tecnologías con las que actualmente trabajamos: OpenERP, Spree y Ruby On Rails. A lo largo de las diferentes entradas de este blog, os informaremos por un lado de las últimas novedades de cada una de ellas, además de contaros nuestros casos de éxito y las noticias corporativas internas.

Muchas gracias por estar ahí, para cualquier cosa que necesitéis os dejamos nuestro formulario de contacto.

¡Arrancamos!

Read more http://factorlibre.com/hola-mundo/

Leer más

OpenObject v6 – Creado repositorio GITHUB

Creado repositorio en GitHub para subir módulos y tener un seguimiento del funcionamiento.


Empiezo con agpti_base_contact v0.05

Podéis ver lo que hace en el fichero __openerp__.py

Link:

https://github.com/JuanjoA/OpenERPv6_agptic_modulos

Leer más

¿Que es Tryton?

¿Que es Tryton?

Tryton es un framework de desarrollo de alto nivel basado en OpenObject, framework de OpenERP. Este fork de OpenERP, al igual que OpenObject, esta desarrollado en python y usa PostgreSQL como base de datos. Surge de la necesidad de un grupo de programadores de crear un proyecto comunitario y participativo y más democrático en la toma de decisiones que OpenERP.

OpenERP es lo que denominan Commercial Open Source Project (Proyecto de Código Abierto Comercial) esto quiere decir que el código es abierto y GPL, cualquiera puede usarlo, redistribuirlo y colaborar en su desarrollo, pero la empresa OpenERP S.A. es la encargada de decidir que mejoras se incluyen en el proyecto y cuales no. Esta restricción hizo que empresas que colaboran con el proyecto hayan desarrollado mejoras que al final OpenERP S.A. ha decidido no incluir en OpenERP. Así Tryton aparece como una alternativa 100% libre, como una meritocracia, en la que el proyecto es gestionado por la comunidad, de hecho se esta creando una fundación para gestionar el proyecto y con el principal objetivo de mantener el proyecto abierto y que no dependa de una sola empresa.

OpenObject es un framework excelente, es decir el núcleo de la aplicación es muy bueno, entonces ¿ porque hacer un fork de un proyecto que ya es bueno ? Además de la necesidad de mantener el proyecto 100%, OpenERP ha crecido mucho en funcionalidad manteniendo los módulos básicos casi inalterables, así en Tryton se decidió reescribir esos módulos base haciendo uso de las nuevas funcionalidades.

A día de hoy Tryton es un proyecto muy activo, con una comunidad muy fuerte detrás, y una excelente base para el desarrollo de un ERP, o desarrollos a medida, pero todavía tiene mucho camino por delante, y no es una solución final tan madura como OpenERP ni cuenta con la misma cantidad de módulos disponibles. Igualmente, de momento al menos, es un producto más orientado a desarrolladores que a consultores, por lo que la mayor parte de la documentación disponible es técnica, no funcional.

Actualmente Tryton se encuentra en su versión 2.2 y cuenta con los siguientes módulos base:  Contabilidad, Facturación, Administración de Ventas, Administración de Compras, Contabilidad Analítica y Administración de Inventario.

Web oficial: http://www.tryton.org/es/

Leer más

Instalar Zoook en Ubuntu – Parte IV: Zoook – Parametrización y conexión OpenERP

Parte final de esta serie de artículos dedicados a Zoook. En esta parte y, una vez terminada la instalación de Zoook, procedemos a su parametrización y a su conexión con base de datos y con OpenERP.

Por último crearemos artículos de prueba y comprobaremos que se exportan correctamente.

NOTA: Consulte la parte III de esta serie de artículos que ha sido actualizada debido a que los repositorios de Launchpad de Zoook han sido eliminados.

Read more http://www.domatix.com/instalar-zoook-en-ubuntu-parte-iv-zoook-parametrizacion

Leer más

Conector de MRW para OpenERP (dx_mrw_connect)

Conector de MRW para OpenERP (dx_mrw_connect)

En Domatix se ha estado trabajando en un módulo que permite la conexión de entre OpenERP y MRW. MRW utiliza un sistema cerrado que permite exportar e importar ficheros de texto plano, por lo que el desarrollo ha consistido en la creación de ficheros importables en la aplicación de MRW y la importación de ficheros generados por esta aplicación.

 

Para esta primera versión del conector se han desarrollado el proceso de ficheros IAPI e IAPO.

 

  • Un IAPI se importa en la aplicación de MRW siguiendo un formato y contiene la información de un pedido de compra. Habrá que generarlo en OpenERP desde un pedido cumpliendo con el formato especificado.

  • Un IAPO se genera en la aplicación de MRW y contiene información sobre albaranes de entrada. Habrá que proveer de un sistema de importación de estos ficheros en OpenERP.

 

En https://github.com/domatix/openerp-dx_mrw_connect se ha publicado el proyecto y está disponible para su descarga.

 

Datos de Configuración

 

Para la generación e importación de ficheros de MRW necesitaremos los siguientes campos en OpenERP:

  • Código de Cliente de MRW

  • Código de Campaña de MRW

  • Ruta de generación de ficheros IAPI

  • Ruta de importación de ficheros IAPI

 

En principio según lo visto en el proyecto se ha asociado la configuración de datos de mrw a la tienda, y se ha asociado la tienda en el pedido de compra.

 

 

Configuración de la tienda

 

 

La importación y exportación de ficheros sigue la siguiente nomenclatura de ficheros MRW:

 

<nombre del interfaz>_<cliente>_<campaña>_YYYYMMDDHHMMSS.txt

 

Donde:

  • nombre del interfaz será: IAPI o IAPO

  • cliente: código de cliente asignado por MRW

  • campaña: código de la campaña asignado por MRW

 

Codificación ISO 8859-1 (ISO Latín 1)

Generación del IAPI

 

Se ha asociado al pedido de compras un nuevo objeto que representa el IAPI.

 

En el formulario del pedido de compras se ha añadido una nueva solapa de MRW con el campo tienda, el campo del IAPI y un botón que genere el fichero en el directorio asociado en la configuración de la tienda.

 

Pedido de Compra – Generación del IAPI

 

Los campos obligatorios para crear el IAPI que tenemos que recuperar de OpenERP son:

  • Código de cliente, asociado a la tienda asociada al pedido de compra.

  • Código de la campaña, asociado a la tienda asociada al pedido de compra.

  • Ruta del fichero, asociado a la tienda asociada al pedido de compra.

  • Código del pedido, código del pedido de compra del propio OpenERP.

  • Fecha de creación del IAPI.

  • Fecha estimada de entrada, por defecto el día siguiente al de creación.

  • OD, nombre del proveedor en OpenERP.

  • Nº linea, del pedido de OpenERP.

  • Código del artículo, será el código del artículo en Magento, en OpenERP al sincronizar con Magento se almacena en magento_sku.

  • Cantidad, la pedida en OpenERP.

 

La generación del fichero del IAPI en principio será manual pero en el futuro se podrá ampliar el desarrollo para generarlo automáticamente al validar el pedido de compra.

 

El botón de generar el IAPI sólo se podrá ejecutar si el pedido de compra está validado, no se podrá ejecutar si está en estado de solicitud de presupuesto o si ya se ha entregado.

 

 

Importación del IAPO

 

Para la importación de IAPO se ha creado un nuevo objeto con los siguientes campos:

  • nombre del fichero

  • fecha de creación

  • Mensajes o histórico

  • Estado (Borrador, Procesado, Error, Cancelado)

  • Listado de líneas del IAPO

 

Workflow de Importación de IAPO

 

Se ha creado un workflow que gestionara el paso de un estado a otro del objeto que representa la importación de un IAPO.

 

El funcionamiento es el siguiente:

  • Creación de una Importación de IAPO, se creará un registro de importación en estado borrador, con la fecha actual, y el nombre del fichero. Podremos guardar en borrador o procesar para pasar al siguiente estado.

  • Al procesar el IAPO, si hay algún error con el formato del fichero o los datos del mismo el registro pasará al estado Error.

  • Si al procesar el IAPO los datos son correctos el IAPO pasará a estado Procesado, se crearán los albaranes que corresponda y se podrán consultar desde el propio IAPO en su historial.

  • Si los datos del IAPO son correctos y da un error que se pueda solucionar desde OpenERP se podrá reprocesar el IAPO para que pase de Error a Procesado una vez solucionado el problema en OpenERP.

  • Un IAPO en estado error o borrador se podrá cancelar para que pase a estado cancelado y no tenerlo en cuenta en posibles revisiones de IAPO erroneos.

 

En el listado de Procesamiento de IAPO, se puede observar a simple vista el estado de un procesamiento según el color de la línea.

Azul = Borrador

Verde = Procesado

Rojo = Error

Gris = Cancelado

 

Listado de Procesamiento de IAPO

 

También se permite filtrar por un determinado estado con lo que se podrá comprobar a simple vista si se ha producido algún error en el procesamiento del IAPO.

Procesamiento automático de IAPO

 

Se ha creado una acción de servidor que automáticamente comprueba si se ha creado algún fichero en los directorios indicados en la configuración de cada tienda.

 

 

Si desde la última comprobación se ha creado algún fichero se crea el procesamiento de IAPO y se intenta validar, si el fichero es correcto y se corresponde con los datos del sistema se importará el IAPO se validará el albarán correspondiente y el procesamiento pasará a estado Procesado.

 

Si al intentar validar hubiese algún error el procesamiento quedaría en estado error y se guardaría el mensaje de error correspondiente.

 

Errores de procesamiento del IAPO

 

Si al procesar un IAPO surgiese algún error se quedaría almacenado el mensaje en el sistema y el Procesamiento de IAPO quedaría en estado Error. Si fuere un error de datos que se pudiese solucionar en OpenERP se podría intentar solucionar y volver a procesar. Si fuese un error en el fichero se podría cancelar para que no apareciese como erróneo.

 

Los errores que se contemplan son los siguientes:

 

  • No existe el proveedor:

‘Error – Proveedor [cod_proveedor] de la linea [num_l] del IAPO no existe en OpenERP’

 

  • No existe el pedido:

Error – Pedido de compra [demanda] del proveedor [od] de la linea [num_l] del IAPO no existe en OpenERP’

 

  • No existe el producto:

Error – Producto [cod_producto] de la linea [num_l] del IAPO no existe en OpenERP’

 

  • No existe el proveedor:

 

‘Error – Linea del pedido de cantidad [‘+line.cantidad_original+’] del producto [‘+line.articulo_id+’] de la linea [‘+line.num_l+’] del IAPO no existe en OpenERP’

 

  • No existe el movimiento:

 

‘Error – Movimiento de la linea [‘+line.num_l+’] del pedido de compra [‘+line.demanda+’]del IAPO no existe en OpenERP’

 

  • Error de formato o leyendo el disco:

 

‘ERROR – Importando el fichero ‘+file_path+’, no se ha podido leer el fichero o no cumple las especificaciones’,‘iapo_id’:iapo_id

 

Read more http://www.domatix.com/es/blog/conector-openerp-mrw

Leer más

thinkting!: OpenERP online

Tras muchos meses de trabajo estamos orgullosos de presentaros thinkting!. Con esto de las modas de Internet, se nos haría mucho más fácil (y sería más «cool») definir thinkting! utilizando términos complicados como «un servicio SaaS sobre OpenERP», «el cloud computing aplicado a los ERP», «tu instancia OpenERP en la nube»… Pero no somos mucho de modas 😉 y nos gusta más «Software de gestión (OpenERP) online (en Internet) sin complicaciones (proceso de alta personalizado rápido y sencillo, además de acceso a una plataforma de formación)».

Leer más

Actualmente estamos desarrollando en Domatix una integración de MRW para OpenERP. La forma en que la aplicación de MRW se conecta con otros sistemas es mediante el intercambio de ficheros, así que la integración que se está desarrollando consiste en generar ficheros procesables por la aplicación de MRW y crear un proceso de importación de ficheros generados por MRW, con el que podamos gestionar los errores de importación.

El sistema de gestión de MRW genera y procesa diferentes archivos para controlar todo el proceso logistico. En esta primera fase de nuestro conector se va a poder generar un IAPI (Previsión de entrada) desde un pedido de compras validado de OpenERP, para indicar a MRW que espera la recepción de esos artículos. Y cuando MRW realice ese envio a almacén generará un IAPO (Mercancia Recepcionada), en nuestro módulo indicaremos donde se encuentran esos ficheros y los procesará, validando los movimientos de stock asociados al pedido de compras que generó el IAPI. En el Procesamiento del IAPO se pueden producir muchos errores por incoherencia en los datos en los dos sistemas así que también se esta desarrollando un completo sistema de control de errores con mensajes para que el usuario pueda saber que ha generado la importación de un IAPO y si no se ha podido importar o generar la acción prevista cuales han sido los motivos.

Con esto conseguiremos una recepción de materiales automatica en los envios gestionados por MRW.

En breve liberaremos el desarrollo y realizaremos un apunte más completo del funcionamiento. Permaneced atentos al blog.

Read more http://www.domatix.com/es/blog/integracion_mrw_openerp

Leer más

Presentando KafkaDB

Hoy queremos presentaros KafkaDB, nuestra nueva criatura que acabamos de publicar en bitbucket. KafkaDB es una herramienta que simplificará la tarea de migrar bases de datos entre versiones de OpenERP, pero también se podría extender para permitir la migración entre versiones entre otras aplicaciones basadas en PostgreSQL. En la página principal del proyecto, podéis encontrar información detallada sobre el diseño y como utilitzarla, pero ahora quería haceros cinco céntimos de cómo hemos llegado hasta aquí.

Los requerimientos

Desde que OpenERP SA anunció que las herramientas de migración no formarían parte del software público empezamos a dar vueltas en cómo podríamos implementarlas de forma reutilizable. Algunas empresas buscaron soluciones a corto plazo, simplemente mirando de solucionar el problema para uno o dos clientes que querían pasar de la 4.2 o la 5.0 a la 6.0 y posponiendo la búsqueda de una solución real. Nosotros estábamos convencidos que de la misma manera que la herencia había permitido a OpenERP tener centenares de módulos hechos y liberados por muchos desarrolladores, podríamos conseguir lo mismo con las migraciones.

Así que básicamente teníamos que implementar algo que solucionara los siguientes requerimientos:

  • Modular: tenía que proveer un mecanismo mediante el cual se pudieran reutilizar las transformaciones de datos de una base de datos a otra.
  • Rápido: dada la medida de las bases de datos de algunos de nuestros clientes, sabíamos que tendríamos que mover la información a nivel de base de datos.
  • Fácil de compartir: además de ser modular, queríamos asegurarnos que sería sencillo para todo el mundo compartir sus transformadas. Dado que la información sobre la migración no estaría incluida en los módulos, necesitábamos que fuera sencillo de compartir, así cómo de encontrar qué transformadas había disponibles.

Búsqueda y desarrollo

Nos ha costado un cierto tiempo hasta llegar al diseño actual de KafkaDB. El proceso empezó con una pequeña prueba de concepto utilizando Python y openetl, un ETL creado por OpenERP SA, pero abandonado este mes de junio. Descartamos esta opción, no tan sólo porqué estaba abandonado, sino también porqué la API no era intuitivo. Además, a pesar de que no llegamos a hacer pruebas, parecía que podía ser relativamente lento.

La primera alternativa fue buscar otro ETL basado en python. Esta vez el candidato fue el Brewery. Éste tenía una API bastante mejor pero no disponía de algunas funcionalidades básicas que necesitábamos y a pesar de que habríamos podido contribuir al proyecto, necesitábamos centrarnos en solucionar los problemas que teníamos, no a implementar un ETL desde cero.

Habríamos querido que fuera en python, especialmente para hacer más sencillo que la gente contribuyera, pero empezamos a buscar alternativas en otros lenguajes. Scriptella fue el primer candidato y éste basa su configuración en un fichero XML, así que nos pareció atractivo. Ya sabíamos que el sistema que escogiéramos acabaría teniendo un fichero de configuración, así que a primer vistazo parecía que esta podía ser una buena opción porque el sistema ya dependía de uno. A pesar de esto, no nos convenció el comportamiento por defecto de algunas opciones del sistema, además del hecho que el XML parecía que podría ser poco práctico puesto que fácilmente podíamos llegar a las 400 tablas.

Así que Àngel, uno de mis socios y nuestro experto en Kettle y grandes migraciones de datos, empezó a jugar con la API de Kettle y mirar a ver qué se podía hacer con transformadas manuales y algunos automatismos. Pronto se dio cuenta, que no tan sólo podía cumplir todos los requerimientos que teníamos, sino que además, permitíamos que personas que no fueran desarrolladores también se podían migrar su base de datos. Por ejemplo, varios de nuestros clientes se lo podrían hacer ellos mismos si lo desearan!

Además, Kettle es probablemente el ETL estándar de facto y especialmente entre la comunidad OpenERP (gracias a Terminatooor, un conector para Kettle creado por Akretion, especialmente diseñado para funcionar con OpenERP).

En resumen, a pesar de que KafkaDB no está acabado del todo todavía, estamos convencidos que constituye una buena base para el sistema de migraciones flexible que necesitamos, no tan sólo para migrar información entre versiones de OpenERP, sino también entre aplicaciones diferentes siempre y cuando se necesite reutilizar el proceso para diferentes bases de datos con estructuras parecidas.

Leer más