Publicaciones etiquetadas ‘ERP’

Presentando KafkaDB

Hoy queremos llevar a cabo la Presentación KafkaDB, nuestra nueva criatura que acabamos de publicar en bitbucket.

Os mostramos KafkaDB, 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 utilizarla, pero ahora me gustaría explicaros como 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

A continuación, explicaremos el camino hasta alcanzar el diseño actual de KafkaDB.

El proceso empezó con una pequeña prueba de concepto utilizando Python y openetl.

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 priori 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 dió cuenta, que no tan sólo podía cumplir todos los requerimientos que teníamos. Sino que, 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).

Presentación KafkaDB

Conclusiones

En resumen, a pesar de que KafkaDB no está acabado del todo todavía, consideramos, que constituye una buena base para el sistema de migraciones flexible que necesitamos.

Por una parte, para migrar información entre versiones de OpenERP, y que además, también lo permita entre aplicaciones diferentes.

Será viable, siempre y cuando se necesite volver a utilizar el proceso para diferentes bases de datos con estructuras parecidas.

Si desea obtener mas información relacionada con el tema de la “Presentación KafkaDB” puede visitar nuestro sitio web haciendo clic aquí.

Multicompañía en OpenERP 6

Módulo Multicompañía – crear compañía

Lo primero que necesitamos para trabajar con OpenERP en multicompañía es añadir a nuestro usuario el grupo “Useability / Multi companies”. De esta forma podremos ver los campos referentes a la multicompañía.

Si nuestro usuario tiene asignado este grupo podremos ver el menú /Administración/Compañías, en la ventana de Compañías podremos dar de alta las compañías.

Las diferentes compañías se pueden crear en OpenERP en una estructura de jerárquica. Así, si queremos crear un grupo de empresas llamado A formado por las empresas B y C primero crearemos la compañía A y luego al crear las compañías B y C completaremos el campo compañía padre con la compañía A.

En el menú compañía árbol de compañías podemos ver esta estructura.

Módulo Multicompañía – accesos

Una vez creadas las compañías tenemos que configurar el acceso a los diferentes documentos, conociendo como funciona el control de acceso a cada compañía. Cada usuario tendrá una lista de compañías a las que se le permite el acceso, y entre esas compañías una será la compañía actual.

Si vamos al menú de usuarios podemos ver la compañía actual del usuario:

y la lista de compañías a las que tiene acceso:

De esta forma cuando un usuario se conecte a OpenERP lo hará con una compañía, y no tendrá acceso a los datos de otras compañías aunque esté en su lista de compañías autorizadas. Importante: Hay que tener cuidado de no trabajar con el usuario admin en multicompañía, ya que este usuario se salta los controles de acceso multicompañía. Así que lo mejor es cuando se cree una compañía crear un usuario administrador de esa compañía con el que hacer toda la configuración.

Ahora que tenemos claro como funciona el control de acceso podemos ver las “reglas de registro”. Las reglas de registro se encuentran en el menú “Administración/Seguridad” y nos sirven para definir quien va a tener acceso a cada documento. Por ejemplo con reglas de registro podríamos hacer que los comerciales solo puedan ver los pedidos que han creado ellos mismos.

Esto nos va a servir en un entorno multicompañía para definir que documentos podemos ver, por ejemplo:

Un pedido de venta lo podremos ver si no está asociado a compañías o si esta asociado a nuestra compañía o alguna compañía que esté por debajo.

{code hidden:false title:false}[‘|’,(‘company_id’,’=’,False),(‘company_id’,’child_of’,[user.company_id.id])]{/code}

Una empresa la podremos ver si no está asociada a compañías o está asociada a nuestra compañía o alguna compañía por encima o por debajo.

{code hidden:false title:false}[‘|’,’|’,(‘company_id.child_ids’,’child_of’,[user.company_id.id]),(‘company_id’,’child_of’,[user.company_id.id]),(‘company_id’,’=’,False)]{/code}

Módulo multicompañía – otras cuestiones

Hasta aquí hemos visto como crear las compañías y dar acceso a usuarios y documentos. Todavía quedan problemas por resolver para hacer totalmente funcional el sistema multicompañía.

El primer problema que nos encontramos es que la instalación de muchos módulos no está pensada para la multicompañía. Por esta razón, los objetos creados automáticamente en la instalación de un módulo, como las secuencias de pedido del módulo de ventas, sólo se crean para la primera compañía creada. Lo ideal sería que la creación de esos objetos se crease mediante un wizard, y poder lanzarlo en cada compañía, pero de momento nos toca crear esos datos a mano para cada compañía.

Aunque podemos definir una estructura de árbol en las compañías, la consolidación de la contabilidad no está contemplada en este sistema, aunque tenemos cuentas contables virtuales, pero no una forma automática de crear todas las correspondencias.

Otro problema que se está planteando en el canal irc de openobjects es como podemos restringir diferentes accesos de un usuario para cada compañía, por ejemplo un usuario que tenga acceso a compras y ventas en una compañía pero solo a ventas en otra compañía. De momento tampoco podemos contemplar esto y la solución sería crear dos usuarios distintos.

Para más información sobre OpenERP visita nuestra web haciendo un clic aquí.

Fabricación

Datos maestros

Listas de materiales maestros describe la lista de materias primas o subproductos que se utilizan para fabricar un producto terminado. La estructura jerárquica permite gestionar listas multinivel de materiales de varios niveles de los materiales.

Listas de componentes de los materiales componentes son componentes y sub-productos que se utilizan en las Listas de materiales maestros.

Rutas define la lista de operaciones que se realiza en un centro de trabajo de montaje o de fabricación de un determinado producto. Una lista de materiales puede ser vinculados a una ruta, que describe la forma de montaje o de fabricación del producto.

Los Centros de trabajo son unidades independientes dentro de la planta de fabricación, consistentes en una o varias personas y/o máquinas. Los Centros de trabajo se utilizan con el propósito de planificar la capacidad y hacer previsiones.

Planificación

Calculo de temporizadores. El temporizador es el corazón del sistema del ERP en términos de planificación. Organiza las órdenes de fabricación basadas en las prioridades (sub-productos de fabricación, fechas requeridas, etc), lanzamientos de órdenes de compra para los componentes que faltan y asigna productos en stock.

La herramienta del temporizador es normalmente planificada para ser lanzada de forma automática una vez al día. Esta frecuencia se puede ajustar según los sectores de su empresa y sus necesidades. También puede ejecutarse de forma manual en caso de ser necesario.

Fabricación

Órdenes de fabricación describe la lista de materias primas que se utilizarán para cada etapa de producción. La materia prima puede ser consumida de una sola vez o de forma progresiva durante el proceso de producción. Además OpenERP proporciona una gestión de desechos, la producción parcial también es posible.

Las Órdenes de compra programarán una propuesta para la adquisición automática del producto que necesita reposición. Esta contratación iniciará una tarea, ya sea una forma de orden de compra para el proveedor, o una orden de producción dependiendo de la configuración del producto.

Las Órdenes de trabajo son operaciones de fabricación requeridas para producir o ensamblar productos. Las diferentes Órdenes de trabajo tienen diferentes efectos sobre los costes de fabricación y planificación, en función de la carga de trabajo disponibles.

Control

Abastecimiento en excepción. En el proceso de planificación de los requerimientos de material (MRP), las órdenes de abastecimiento se crean para lanzar órdenes de producción, órdenes de compra, distribución del inventario, etc… Las Órdenes de abastecimiento se generan de forma automática por el sistema y a menos que haya un problema, el usuario no recibirá ningún tipo de notificación.

En caso de problemas, el sistema lanzará algunas excepciones de abastecimiento para informar al usuario sobre los problemas de bloqueo que deben resolverse de forma manual (como por ejemplo la falta de estructura de Lista de materiales (LdM) o falta de proveedor).

Informes

“Carga del centro de trabajo” es una proyección de cargas en un centro de trabajo para un determinado período. La carga se expresa en horas (para recursos humanos) o ciclos (para máquinas)

“Variación del valor semanal de las existencias” permite seguir la evolución del valor de las existencias, de acuerdo al nivel de las actividades de fabricación (consumo de materias primas, producción de productos terminados, estimación del valor añadido de las existencias) a medida que avanzan en el proceso de transformación.

también le adjuntamos a continuación el enlace a nuestra web, haceindo clic aquí.

¿Es mejor para mi empresa el software libre?

Actualmente existe un debate, alimentado especialmente por las empresas de software libre cuyo modelo de negocio está basado en la venta de licencias de sus productos.

La polémica aparece cuando queremos comparar; si el software libre está o no, a la altura de competir con sus homólogos privativos.

Como apunte técnico, podemos anotar que la única diferencia entre el software libre y el propietario es su licencia de uso, es decir, te permite una libre distribución y entrega del código al cliente final.

Por lo que, comparar ‘software libre’ con ‘software propietario’ es un error de raíz.

La característica “libre” del software es, que a cualquier empresa le permite simplemente con un cambio de licencia, conceder a su producto una ventaja competitiva.

Ese cambio de licencia resulta impensable para muchos distribuidores que ya cuentan con un producto privativo bien posicionado en el mercado.

Pues, podría suponer, perder los ingresos proporcionados por la venta de licencias.

También tendría que mejorar, la calidad del código como los servicios en torno a su producto. Y lo más importante, perder el monopolio de la distribución, es decir, el control sobre su propio desarrollo.

Entre la categoría de productos ERP con licencias restrictivas se encuentran Microsoft Navision, Dynamics AX (antiguamente Axapta), SAP (Business One) o Sage, entre otros.

Tendencia del sector del software libre

Hoy en día, y como ya se explica en otras secciones, el software libre ya es un líder indiscutible en muchos sectores del mercado, como la gestión de servidores (data centers, cloud computing, big data, etc…), web (CMS, comercio electrónico), smartphones y tablets (Android es un sistema libre basado en GNU/Linux).

Y de un tiempo a esta parte, sectores claramente dominados por compañías de desarrollos privativos, como los ERPs, están siendo amenazadas por los nuevos cada vez técnicamente más competitivos, productos libres.

De hecho, es cuestión de tiempo que estos productos acaben adaptándose a un nuevo mercado, ajustando los precios, mejorando la calidad, liberando el código.

En resumen llevando a cabo acciones diferentes par poder continuar ofreciendo, cualquier otro valor añadido para poder competir.

Posiblemente los que no sepan adaptarse, terminen desapareciendo, dejando sin soporte ni servicio a sus clientes.

De esta manera se continuara fortaleciendo la idea de que las herramientas de gestión de su empresa deberían ser libres y así podrá evitar estos problemas.

Las herramientas de gestión empresarial deberían estar disponibles bajo licencias 100% libres.

Tradicionalmente, el modelo de desarrollo de software libre, ha permitido un notable distanciamiento tecnológico sobre sus competidores propietarios.

Si conseguimos generar un modelo de negocio alrededor de la venta de servicios sobre el software, y en lugar de vender el software en sí mismo, conseguiremos que este último se mejore de manera constante y continua.

Y cuando desaparece la necesidad de empaquetarlo y venderlo como una nueva versión, conseguimos alcanzar una calidad técnica superior.

En este sentido, puede ser muy beneficioso contar con software libre empresarial para el crecimiento de su empresa.

“Los conceptos de software libre y software de código abierto, no son nociones relativas a una tecnología determinada, marca o producto, sino que expresan una característica jurídica.“

Siga leyendo: Comparativa entre modelos de desarrollo ERPs libre y propietario

También puede encontrar información relacionada con el artículo haciendo clic aquí.