Entradas

Creación y validación de cuentas bancarias en OpenERP

Crear una cuenta bancaria IBAN

Al crear una cuenta bancaria, seleccionando “Tipo de cuenta bancaria”: “Cuenta IBAN”, se tendrá que indicar en el número de cuenta el número de cuenta con los dos dígitos del país y los dígitos de control de la cuenta IBAN. OpenERP comprobará que el formato de la cuenta IBAN es correcto. A parte es necesario indicar el banco al que pertenece la cuenta, y que este banco tenga asociado un “Código de identificación bancario”.

ficha producto

Crear una cuenta bancaria de España

Si al crear la cuenta bancaria se indica el tipo como “Cuenta Bancaria Normal” y el país España al introducir el número de cuenta hará lo siguiente:

  • Comprobar que el código tiene 20 dígitos
  • Comprobar que el cálculo de los dígitos de control es correcto
  • Asociar el banco correspondiente a la cuenta indicada

ficha producto

Crear una cuenta bancaria extranjera que no sea IBAN

Trabajando con el extranjero puede darse el caso de tener que introducir una cuenta bancaria de otro país de la que no se conoce el código IBAN, para esto si se introduce el tipo como “Cuenta Bancaria Normal” y el país es distinto a España, se podrá introducir el número de cuenta sin ninguna restricción de formato.

ficha producto

Gracias a la modularidad de OpenERP es posible comprobar el formato de las cuentas bancarias españolas, y si fuese necesario se podría crear la validación de cuentas bancarias de cualquier otro país.

Colaborar en proyectos de Launchpad

Registrarse en Launchpad

Para registrarse en Launchpad hay que acudir a su web:

https://launchpad.net/

y hacer clic en la parte superior derecha, donde pone “Register”. Automáticamente se muestra un formulario, donde que hay que hacer clic en “Crear una cuenta nueva” (omitir este paso si ya se tiene cuenta en Launchpad).

En el formulario de registro habrá que indicar un nombre de usuario, muy importante ya que será parte del nombre de nuestras ramas de código, y una dirección de correo a la que nos llegarán las notificaciones.

Vincular nuestros sistemas a nuestra cuenta en launchpad

Para poder utilizar desde nuestro sistema el usuario creado en Launchpad hay que vincular el sistema con la cuenta, para esto se utilzan las claves ssh. Con el siguiente proceso crearemos una clave publica y una privada en nuestro sistema. En Launchpad se guardará la clave pública, y cuando nuestro sistema necesite acceder a nuestra cuenta en Launchpad consultará si coincide la información de la clave publica con nuestra clave privada para ver si nuestro sistema tiene o no permisos para acceder a la cuenta.

Para generar las claves ssh, en un sistema con Ubuntu/Mint o basado en Debian:

Instala OpenSSH

sudo apt-get install openssh-client

Genera la clave
ssh-keygen -t rsa

– Presiona intro para aceptar el nombre por defecto
– Introduce la contraseña

Este proceso crea en /home/usuario/.ssh las claves, id_rsa la clave privada y id_rsa.pub la clave pública.

Ahora en la cuenta creada de Launchpad se debe indicar cual es la clave pública, haciendo clic en “SSH Keys” y copiando el contenido de /home/usuario/.ssh/id_rsa.pub

Descargar el código con Bazaar

Bazaar es el sistema de control de versiones con el que trabajan los proyectos alojados en Launchpad. Para instalarlo en un sistema Ubuntu/Mint  o basado en Debian se ejecuta el siguiente comando:

apt-get install bzr

Para indicar en nuestro sistema con que usuario de launchpad vamos a trabajar ejecutamos

bzr login nombre_usuario_launchpad

este comando sólo es necesario ejecutarlo una vez, cuando se instala bzr. Si siempre se trabaja con el mismo usuario no es necesario volver a hacer ‘Login’ en el mismo sistema.

Para descargar el código del proyecto utilizaremos el comando “bzr branch lp:proyecto/version”, que crea una rama para trabajar en local con la copia de la versión del proyecto indicado, por ejemplo:

bzr branch lp:openerp-spain/6.0

Opcionalmente se puede añadir un parámetro para indicar en que directorio se quiere guardar la rama, si no utilizara lo que haya después del último “/”, en el caso anterior lo almacenaría en el directorio “6.0”.

Añadir código en nuestra rama local

Una vez se han realizado los cambios necesarios en el código local que tenemos del proyecto hay que indicar esos cambios en el control de versiones. Las siguientes operaciones se realizarán desde dentro de la carpeta que hemos descargado, en el ejemplo anterior en “6.0”.

Si hemos creado nuevos ficheros hay que añadirlos al control de versiones, esto lo se hace con:

bzr add *

se utiliza * para añadir todos los ficheros, aunque es posible indicar los ficheros de forma individual.

Tanto si se han añadido ficheros al control de versiones como si no, cuando el código se ha modificado, habrá que indicarlo realizando un “commit” indicando que modificación se ha realizado:

bzr commit -m “mensaje”

El mensaje es aconsejable que tenga el siguiente formato “[TAG] descripción”. La etiqueta [TAG] por convenio se utilizan las siguientes opciones:

  • [IMP]: Mejoras
  • [FIX]: Corrección de errores
  • [REF]: Refactorizar, modificar el código sin cambiar la funcionalidad
  • [ADD]: Añadir fuentes
  • [REM]: Eliminar fuentes

Subir cambios al proyecto (con permisos en el proyecto)

Si el usuario con el que trabajamos tiene permisos en el proyecto actual, se pueden subir directamente estos cambios al proyecto. Esta opción sólo es recomendable para los usuarios con experiencia y responsables del código del proyecto.

Siguiendo con el ejemplo anterior, para subir el código a lp:openerp-spain/6.0 se puede hacer con el siguiente comando:

bzr push lp:openerp-spain/6.0

Subir los cambios a una rama de nuestro usuario y proponer un merge con la rama original (no es necesario permisos en el proyecto)

Si el usuario no tiene permisos en el proyecto para el que pretende subir el código, o si se quiere que otros miembros del proyecto revisen el nuevo código, es posible subir el código a una rama del usuario creado y proponer un merge con la rama original. De esta forma el resto de miembros del proyecto podrán descargar el código de dicha rama para comprobar su funcionamiento, y una vez validado, añadirlo al proyecto principal.

Para subir el código a una rama propia del usuario creado, siguiendo con el ejemplo anterior y suponiendo que el nombre de usuario en Launchpad es “nombre_usuario_launchpad” se puede crear la rama para dicho usuario con el siguiente comando:

bzr push lp:~nombre_usuario_launchpad/openerp-spain/6.0

Ahora es posible ver la web de esta rama en:

https://code.launchpad.net/~nombre_usuario_launchpad/openerp-spain/6.0

Y para indicar que se quiere hacer un «merge» (fusión) con el proyecto principal, en esta web, en “Branch merges” se hace clic sobre “Propose for merging” y se completa la información sobre el «merge».

Una vez propuesto el «merge», los usuarios miembros del proyecto podrán probar tu código y añadirlo al proyecto al validar el «merge».

Modo desarrollador del cliente web 6.1 de OpenERP

acerca de

En la ventana emergente que aparece se muestra el enlace «Activar modo desarrollador» en la parte superior derecha, y haciendo clic sobre él se activará este modo y estarán disponible todas las nuevas funcionalidades.

modo desarrollador

Una vez activado el modo desarrollador al acceder desde el cliente a una vista aparecerá una lista junto al titulo con varias opciones.

openerp depurar vista

Por defecto este listado indicará «Depurar Vista#…» y junto a la almohadilla aparecerá el número de la vista.

La primera opción del desplegable anterior es «Ver Campos», haciendo clic sobre él se obtendrá un listado de los campos de la vista actual con los parámetros correspondientes.

campos del modelo openerp

Haciendo clic sobre «Obtener Campos de Vista» se obtendrá el XML generado para mostrar esta vista, ojo, porque si la vista se ha generado usando varias vistas XML extendiendo unas a otras aquí se mostrará el resultado final.

campos de la vista openerp

Al hacer clic en «Gestionar Vistas» se mostrará un listado de las vistas relacionadas con la vista actual. Aquí se podrán crear nuevas vistas, eliminarlas o editarlas, aunque lo recomendable es usarlo solo a modo de consulta y siempre realizar esas modificaciones creando nuevos módulos.

gestionar vistas openerp

El resto de opciones sirven para acceder a editar directamente las vistas relacionadas con la vista actual.

editar vista openerp

Accediendo en un formulario aparecerá una nueva opción, «Ver Registro(perm_read)», que muestra información relativa al registro actual.

ver registro openerp

Por último, al igual que en la versión 6.0 del cliente web, en modo formulario al situar el puntero sobre un campo mostrará información relativa al campo.

información campo openerp

Esta información será diferente en cada tipo de campo, por ejemplo en botones el método al que llama.

información botón openerp

Al situarlo sobre un widget de estado mostrará los posibles estados.

información estado openerp

Prestashop (y OpenERP)

A pesar de su temprana edad, actualmente es la segunda plataforma más popular comparándolo con sus rivales libres más cercanos, de acuerdo con Google Trends,. Sin atrevernos a realizar pronósticos, parece que la tendencia es creciente, mientras que Magento, líder actual indiscutible de plataformas de comercio electrónico, ya parece haber tocado techo. Por debajo de ambas quedan prácticamente empatadas la solución ecommerce más popular para Joomla, VirtueMart y un creciente OpenCart, al que no hay que perder la pista. Y en último lugar, un obsoleto OsCommerce, que tal y como se obseva fue pionero y líder indiscutible en años anteriores, hasta que aparecieron sus nuevos rivales, tecnológicamente superiores y lo destronaron sin compasión.


capturas_openerp

Fecha de la captura: Julio 2012. Enlace actualizado en Google Trends.

¿Por qué Prestashop? ¿Y por qué ahora? En Domatix tenemos mucha experiencia con ecommerce, aunque en los últimos años nos hemos concentrado en soluciones que conectaran con OpenERP. Lamentablemente, descartando osCommerce por ser un producto ya obsoleto, y Zoook, solución que también se las prometía, únicamente nos queda Magento. Magento es un excelente producto, muy completo y complejo, pero por ello quizás costoso levantar, y mantener un ecommerce con esta plataforma. La curva de aprendizaje del usuario final también es elevada y por ello otras soluciones más sencillas pero no por ello menos completas ahora mismo están en auge.

Y ahí es donde entra Prestashop, que además ya cuenta con una base de clientes enorme, pero todavía no ofrece la posibilidad de conectar con OpenERP. Para solucionar esta carencia, Akretion y Camptocamp, dos grandes de OpenERP, han unido sus fuerzas, tal y como pulicaron en su nota de prensa y pretenden proporcionar un conector que permita a Prestashop gestionar la tienda y ventas utilizando como BackOffice a OpenERP, para gestionar los stocks, finanzas, incidencias, pedidos, etc…

Aunque ya existe un conector anterior, desarrollado por TechReceptives, llamado openerp_prestashop_sync, actualmente alojado en un repositorio de Bitbuckett, éste aún no ha conseguido llegar a una versión estable y proporcionar una buena conexión e interoperabilidad con OpenERP. Tampoco parece que la aproximación técnica para realizar las tareas de conexión sea la más adecuada.

Para cubrir este nicho actual, la alianza de Akretion y Camptocamp con la presentación de prestashoperpconnect puede ser determinante, y esperamos contar en breve con una versión 100% funcional y estable de su nuevo conector.

Actualmente en Domatix estamos probando todo el trabajo realizado y aunque todavía no parece preparado para entrar en producción en una tienda ya funcional, algunas de las tareas básicas del conector se realizan  sin problemas.

En breve estaremos informando con novedades al respecto.

Mejorar control de envíos desde pedidos (módulo OpenERP)

Para cubrir esa necesidad, hemos creado el módulo dx_sale_line_delivered, que mejora el módulo base y añade los siguientes campos a la linea del pedido:

  • Enviado, cantidad enviada, obtenida de los albaranes asociados y validados, hasta que no se valida un albarán no lo tiene en cuenta.
  • Stock real, el stock que hay en los almacenes.
  • Stock disponible, es el stock de los almacenes restando el reservado y añadiendo el pendiente de recibir.

Con esto no sólo conoceremos el estado de envío de cada linea de pedido, sino que tendremos accesible también la información del stock real y disponible para poder estimar cuando podremos servir los productos restantes.

El módulo esta liberado bajo AGPL y está disponible en launchpad https://code.launchpad.net/~domatix/dx/6.1 y en http://apps.openerp.com/addon/7655

Reflexiones sobre la ponencia de licencias libres en las Jornadas OpenERP 2012

  • Igualar Copyleft y AGPL. De acuerdo con la FSF : «Copyleft es un método general para hacer un programa (u otro tipo de trabajo) libre, exigiendo que todas las versiones modificadas y extendidas del mismo sean también libres». Es por tanto, un concepto, una idea, sobre la cual luego se pueden aplicar diversas licencias (las principales, y recomendadas por la FSF: FDLv1.3, FDLv1.2, FDLv1.1, GPLv3, GPLv2, GPLv1, LGPLv3, LGPLv2.1 y AGPLv3 de GNU).
  • Aunque pueda sonar raro, Copyleft no sustituye a Copyright, es más, lo necesita. ¿Como? Si, es así dado que si el código fuera liberado bajo dominio público, cualquiera podría «adueñarse» de él, y convertir en privativo cualquier derivado del mismo. Es difícil encontrar programas libres (Ayuda-Acerca de) que no están registrados bajo Copyright, precisamente porque es necesario para proteger su licencia libre. Aunque sería posible utilizar un registro diferente al Copyright para licenciar software libre, en la práctica esto no se hace (ni es recomendable).
  • Tampoco es aplicable al software las licencias Creative Commons (pensadas para otro tipo de trabajos, no software), explicadas muy bien aquí. Las licencias Copyleft para software son las mencionadas anteriormente.
  • Libre no es igual a gratis. Un error de base que puede confundir a muchos. Extraído, nuevamente de la FSF (punto 4): «Usted podrá cobrar cualquier importe o no cobrar nada por cada copia que distribuya, y podrá ofrecer soporte o protección de garantía mediante un pago.» Todos los que hemos trabajado con Joomla o Magento y hemos comprado extensiones GPL ya lo sabemos. También existen soluciones verticales de OpenERP que tienen un coste de «distribución y soporte», que no licencia de uso.
  • Es necesario entender que el propietario del código es quien lo hace, y aunque el desarrollo sea colaborativo, dicha regla no cambia. Así, podemos encontrar desarrollos como Tryton, que cuenten con varios Copyrights, ya que al ser un fork de OpenERP cuenta con código realizado por diferentes partes. No hay un único autor, o un único propietario del programa. En este caso para realizar un cambio de licencia sería necesario un acuerdo unánime entre todas las partes.
  • Revisando rápidamente otros puntos de la presentación:
      1. Garantía de que nunca pase a ser código cerrado: las licencias libres no ofrecen esa garantía. Un software puede cambiar de licencia cuando el propietario así lo decida, como de hecho ha pasado (como ya explicamos aquí, en el supuesto 2)
      2. No puede haber otro beneficiario que no sea el autor: es un error de base. Por supuesto que yo puedo tomar un proyecto, modificarlo y revenderlo. Esto es lo que hace RedHat, entre otros. Pero es lógico que pueda ser así, de otra manera todos los beneficios irían al que escribió la primera línea de código del kernel, o de la base de datos o de la librería principal que utiliza el software.
  • Por lo demás, la diferencia entre software libre y software privativo, es básicamente una característica jurídica. No se es mejor software (técnicamente hablando) por ser libre, y hay buenos y malos programas tanto libres como privativos. El software privativo sólo necesita un cambio de licencia para volverse libre, y viceversa. No posiciona mejor en Internet mágicamente ni va a atraer una comunidad que se haga cargo de mantenerlo, si bien con el trabajo adecuado esto puede ser posible.

Como la mayoría de reflexiones ya se hicieron en su momento para el portal openerpspain, recomendamos la lectura del artículo:

¿Es mejor para mi empresa el sofware libre?

Otra pequeña aclaración: las licencias libres no obligan a liberar código realizado, lo que obligan es a distribuir los binarios junto con el código fuente. Es decir, si yo tomo un desarrollo libre y lo mejoro para uso propio, no tengo obligación de liberarlo públicamente. Si ese desarrollo lo comercializo o distribuyo, tampoco existe la obligación de liberarlo más allá de las copias con las que se han distribuido los binarios (es decir, a nuestros clientes o amigos). La AGPL sí que va un poco más lejos, y obliga a entregar el código incluso en el caso de que los binarios no se entreguen, como es el caso de los servicios saas.

Yendo más allá, incluso dentro del mundo del software libre, hay conceptos más allá del código. Por ejemplo Android y OpenERP son productos libres, pero las decisiones, el rumbo y el código están marcados y decididos por una única empresa, mientras que otros desarrollos como LibreOffice o Tryton son más comunitarios, digamos, meritocráticos. Las decisiones técnicas y el rumbo del proyecto son decididas por la comunidad de usuarios, y éstos tienen más peso en función de las aportaciones realizadas. Evidentemente cuanto más libre y participativo es un desarrollo, mayor es la posibilidad de atraer una comunidad grande y motivada.

Como se podría hablar mucho más largo y tendido sobre esto, quizás merezca la pena alargarlo en otro artículo más completo, o volver a tratar el tema en una charla o mesa redonda en las próximas jornadas de OpenERP.

Reflexiones tras las Jornadas OpenERP 2012

En primer lugar, enhorabuena al equipo de Avanzosc por la organización. No es una tarea fácil, y una vez más, el equipo de organizadores realizaron un trabajo excelente para facilitarnos a todos los presentes y conferenciantes nuestra asistencia. Recomiendo también la lectura del artículo-resumen «oficial» colgado en la página de las Jornadas.

Sobre el programa, un año más las presentaciones han sido expuestas por distribuidores/partners de OpenERP y por tanto mayoritariamente las preocupaciones y exposiciones son de carácter técnico y funcional, orientadas hacia la comunidad de desarrolladores. Aunque se habló de la posibilidad «censar» a los usuarios finales que se han «auto-implantado» OpenERP (algo imposible de realizar en la práctica, el censo, no la auto-implantación) y de que necesitan un lugar para exponer sus necesidades, carencias y problemática. Si bien lo cierto es que no hay una comunidad ni representación activa de los mismos, y orientar parte del tiempo o esfuerzos hacia éstos creo que no sería tan productivo como dedicar energías a tratar de atraer nuevos implantadores para potenciar la comunidad y que a su vez promuevan OpenERP para seducir a nuevos clientes potenciales y aumentar el número de implantaciones. En definitiva, la «comunidad» de OpenERP está formada por empresas que distribuimos OpenERP, y escuchamos las necesidades nuestros clientes, trabajando de una manera u otra para resolver dichas necesidades. Para soporte adicional, siempre se puede contar con OpenERP s.a.

Sobre las charlas, de varios tipos (nota: no es mi intención describirlas todas, esa tarea ya está realizada en la web oficial de las Jornadas):

Soluciones verticales, como siempre un trabajo excelente de las empresas desarrolladoras, con charlas más completas en gestión de granjas (de dos tipos, cría de animales y huevos), gestión de proyectos según Project Management Institute (excelente trabajo de Eficent), módulo para LOPD (que bien pudiera servir para la localización, ya que es aplicable a todas las empresas),  gestión de recursos para actividades lúdicas de Abartia, y nuestra vertical de transportes, éstas dos últimas no se pudieron ver en directo debido a una caída de la conexión a internet.

Charlas ténicas: a destacar KafkaDB, propuesta para migración de módulos y datos entre versiones de OpenERP, que simplifica el trabajo, pero todavía queda muy lejos ser algo fácil, MongoDB, una excelente alternativa para almacén de datos alternativo y complementario y BABI, un «embrión» de Business Intelligence para OpenERP, aunque lamentablente no va a ser liberado.

Módulos para la comunidad: entre otros, el l10n_es_gestion_comercial, para la gestión de efectos comerciales (cobros y pagos), para el que estamos prestando nuestro apoyo y ayudaremos a dar un empujón y mejorarlo/terminarlo en breve. También a destacar la presentación de Omar Castiñeira, de Pexego para la gestión de la documentación de expedientes.

También vimos la presentación del nuevo proyecto de Carlos Liébana, Factor Libre, al que deseamos mucha suerte desde aquí, aunque no la necesite, excelente comienzo y previsiones aún mejores.

Para dar una nota de color, se presentó el «competidor comunitario» de OpenERP, Tryton. Nosotros mismos sugerimos la charla en la lista de correo, aunque finalmente fue realizada por el equipo de Nan-tic, elección acertada, pues ellos están involucrados muy activamente en la localización española y difusión del proyecto.

Mención especial a la charla sobre los aspectos legales de las licencias GPL y derivadas (como AGPL). Agradeciendo a Helena Fuentes su asistencia y la presentación, como buen conocedor de los aspectos legales sobre las mismas, debo aclarar algunos puntos de la presentación, que lejos de cumplir el objetivo de aclarar conceptos y dilucidar los límites de los derechos de propiedad y licencia, acabaron confundieron bastante más, por tratar algunos temas de manera incorrecta. Quisiera aclarar algunas equivocaciones expuestas en dicha ponencia:

Nota: después de leer todas las aclaraciones, y viendo el tamaño de las mismas, he preferido enmarcar el contenido, y separarlo en otro artículo, de interés para aquellos que deseen conocer más acerca de los fundamentos jurídicos de las licencias libres.

Leer el artículo completo.

Alejándonos un poco de los temas técnicos nos sorprendió agradablemente saber que ya existen empresas cuyo modelo de negocio principal es OpenERP pero no implantan ni desarrollan, sino que vienen del mundo del asesoramiento legal y contable. Complementa los servicios que ofrecemos los partners y enriquece al cliente final, dado que realizan todos los trabajos contables y fiscales sobre la implantación del cliente de OpenERP. Recomendable, como mínimo, conocer a Gafic, porque creo que han abierto una nueva línea y van a ser una referencia a seguir para otros que vengan.

Nuevamente agradecer la presencia oficial de OpenERP s.a, representados por Rubén Real y Frédéric van der Essen, que acudieron para presentarnos las futuras novedades de OpenERP en el cliente web y POS y escucharon pacientemente nuestras sugerencias y aportes para trasladarlos a las personas correspondientes. Enhorabuena por el trabajo realizado y gracias por seguir al pie del cañón, a pesar de que parte de la comunidad española a veces puede parecer un poco hostil con las políticas de OpenERP.

Y por último, y relativo al debate sobre la localización española. Antes que nada pedir perdón por tener que marcharnos apenas unos minutos antes del final, pero nuestros compromisos personales no nos permitieron apurar más tiempo. Pido disculpas a amigos, colaboradores y sobretodo a la organización, por no haber encontrado un momento para despedirnos «oficialmente». Obviamente no podíamos interrumpir el debate, y tampoco pudimos demorar más nuestra marcha.
capturas_openerp
Imagen que no tiene nada que ver con el artículo, pero con suerte puede hacer su lectura más amena 🙂

En el debate, como siempre, varias opiniones, todas ellas correctas desde un punto de vista individual, entendiendo que cada empresa cuenta con unas circunstancias, clientes, experiencia y equipo diferentes, pero muy difícil de unificar, especialmente todo lo relativo a crear formas fiscales o grupos de trabajo «oficiales» o asignación de tareas, distribución de las mismas de manera remunerada (canalizadas, previsiblemente por dicha forma fiscal). Lo cierto es que la localización española siempre ha destacado por su buena trayectoria y rumbo, y si bien es cierto que la mayor parte de trabajo ha sido realizado por muy pocas empresas no es menos cierto que hasta ahora ha funcionado y muy bien. Y las aportaciones y número de contribuidores, aunque discretamente, sigue creciendo. Mi opinión personal es que algo que funciona, y lo hace bien, no debería ser expuesto a demasiados cambios, en especial si algunas de las partes no están conformes con dichos cambios… aunque, una pequeña reflexión al respecto:

Actualmente cuando OpenERP no cubre una funcionalidad, el primer cliente en necesitarla la financia y cuando la empresa desarrolladora la libera, ya está disponible para todos los demás clientes. Es una fórmula muy buena, porque realmente funciona, aunque tiene algunos «peros» de base. Por ejemplo puede ser un requerimiento realmente costoso, y por tanto no asumible por dicho cliente, lo que puede derivar en tres posibles caminos:

  1. El cliente elige otra solución No-OpenERP. Obviamente el peor de los casos. Se pierde el proyecto y la implantación.
  2. El cliente «asume» las carencias. No es una buena solución, pero es mejor que la anterior. Y cabe la posibilidad de que dichos requisitos se desarrollen por otros más adelante.
  3. El distribuidor encuentra que otros de sus clientes actuales pueden estar interesados en dicha solución y los agrupa, dividiendo presupuesto entre todos, para desarrollar dicha funcionalidad.

Al final, en caso de ser desarrollada, todos ganamos, pues ya forma parte de OpenERP o de la localización española. Sin embargo, el «problema» de estos casos es que sin duda perjudican a la comunidad en general por falta de posibilidades y perjudican a las empresas más pequeñas. Ahí si que cabría preguntarse si puede haber una solución que beneficie a todos.

Y quizás la haya…¿sería viable colaborar para el desarrollo de un portal para crowdfunding OpenERP? Algo tipo www.goteo.org pero exclusivo para OpenERP, donde un distribuidor, a petición de un cliente publicara unos requerimientos, y exisitiera la posiblidad de que las demás empresas colaboraran económicamente a dicho proyecto (a través de sus clientes interesados, claro). Creo que estableciendo unas normas claras (1 proyecto = 1 desarrollador, para no crear conflictos), un precio mínimo individual establecido y generado por la división automática del total proyecto entre todos los «pujantes» y sobretodo, liberación automática de todo lo realizado e inclusión en la localización española, podría ser muy bueno para todos. Atraer y generar negocio del que se beneficien todos. Evidentemente habría muchos cabos que atar, el primero de ellos la financiación, crowdfunding o patrocinio del mismo portal, dado que debería ser comunitario y sin ánimo de lucro, pero creo que puede ser viable, aunque sólo participemos una parte de los distribuidores. Para facilitar la salida de desarrollos sencillos e incluso a largo plazo tratar de abarcar cosas más complejas (¿generación de nóminas y laboral? ¿Por qué no, si 100 asesorías «participan» con 50 euros mensuales?).

Otra ventaja es que permanecería el histórico de todo lo realizado, con los análisis y la documentación, para facilitar el conocimiento de todo lo desarrollado (clientes potenciales y otros distribuidores).


capturas_openerp

Un goteo.org para OpenERP ¿buena iniciativa o pésima idea? Dependerá de la comunidad…

En fin, que quizás después de todo lo dicho ya esté pensando de más, pero la necesidad está ahí… Sólo hay que saber canalizarla. En Domatix nos ofrecemos a poner en marcha la iniciativa o colaborar si encontramos el apoyo suficiente. Y si llegamos tarde para la iniciativa, siempre es algo que podemos volver a plantear en las próximas jornadas. Tenemos todo un año para ordenar ideas, y salvo que haya algún impedimento, los ojos están puestos en Valencia para ser el próximo candidato 🙂

Conforme se vayan definiendo un poco mejor las ideas y si vamos recibiendo feedback, iremos actualizando nuestras sensaciones en este blog, a través de twitter, o mediante correos electrónicos, bien a la localización o entre los interesados.

Nuevamente, gracias a todos los que han patrocinado, acudido y charlado en las Jornadas, y espero que nos volvamos a ver el próximo año. Perdón por el tocho y gracias por la lectura.

Avance de OpenERP 6.2

Una de las novedades presentadas en la versión 6.1 fue la vista tipo Kanban. Kanban, cuyo significado viene de las palabras del japonés «kan» significa visual y «ban», que significa tarjeta, es una forma visual de mostrar información utilizada en sistemas de gestión ágiles. La intención de OpenERP s.a para sus próximas versiones, desde OpenERP 6.2 y para la 7, es utilizar este tipo de vista para visualizar todos los documentos de OpenERP.

Por ejemplo para las ventas se pueden ver en un tablero en que cada venta es una tarjeta, y dependiendo de la columna en la que esté la venta se encontrará en un estado del proceso o en otro.

gestion de calidad

Para la versión 6.2 se ha realizado una revisión del diseño, se ha limpiado la interfaz, haciéndola mas simple pero manteniendo la funcionalidad. En la siguiente captura de la vista del listado se puede ver en la parte superior que se han sustituido los campos del buscador por un único campo en el que añadir todos los parámetros de búsqueda.

gestion de calidad

Respecto a la usabilidad, se está trabajando en mejorar y simplificar la interfaz para el usuario final, para que en todo momento sepa lo que tiene que hacer de manera clara y sencilla. Por ejemplo, al visualizar un listado vacío, aparecerá un mensaje que mostrará las indicaciones para crear nuevos documentos.

gestion de calidad

Para hacer OpenERP más social se está trabajando en crear un «muro» tipo Facebook, en el que se mostrarán las acciones realizadas y peticiones de los usuarios, además de permitir la comunicación entre ellos de manera muy fácil y sencilla. En la siguiente captura se puede ver entre otros mensajes, una petición de vacaciones que será posible validar o rechazar desde el mismo «muro», un mensaje indicando que se ha creado un nuevo usuario, y un mensaje de una venta realizada.

gestion de calidad

Estos mensajes podrán crearse en la página de cualquier documento. En la siguiente captura se puede ver una venta, que tiene dos seguidores, y en los mensajes se pueden ver las acciones realizadas en esa venta y la comunicación realizada sobre el mismo.

gestion de calidad

Dichos desarrollos actualmente se encuentran en fase de beta, y no serán estables hasta el lanzamiento de la versión 6.2 de OpenERP.

Comisiones en OpenERP

Después de testear varias alternativas para gestión de comisiones de agentes comerciales nos decidimos por trabajar con el módulo sale_commision. Este módulo permite la gestión de comisiones a agentes comerciales, pudiendo ser un agente comercial tanto un empleado como un autónomo u otra empresa. En cada venta se puede indicar si se desea asociar uno o varios agentes comerciales, y periódicamente se pueden liquidar las comisiones correspondientes a cada agente comercial según lo pactado sobre lo facturado.

En el módulo sale_commission se pueden configurar comisiones fijas o por tramos. Si se utilizan comisiones fijas se indica que comisión en tanto por ciento de lo facturado se va a pagar al agente comercial. Si se configura la comisión por tramos se podrá indicar que tanto por ciento se le va a pagar al agente comercial en función del total vendido.

Como ampliación de este módulo hemos definido otro tipo de comisiones, comisiones por descuento. Con este nuevo tipo de comisiones podemos configurar el sistema para que la comisión dependa del descuento que se aplica en la venta.

gestion de calidad

Aparte de esta ampliación se ha modificado el campo de comisión en las lineas de factura para poder editarlo. De esta forma en una venta puntual se podría indicar manualmente la comisión que se paga al agente comercial.

gestion de calidad

Una posible próxima ampliación para el futuro es añadir poder pagar las comisiones no en función de lo facturado como funciona actualmente, sino en función de lo cobrado finalmente.

Entorno de desarrollo de OpenERP con Eclipse – Parte III: Eclipse

3 Eclipse

3.1 Instalación

  • Hay dos opciones para instalar Eclipse:
    1. A través de apt-get,
    2. Como ejecutable de la página web.

La primera opción garantizará que todas las dependencias se instalen automáticamente.
La segunda opción permite instalar la última versión de Eclipse y asi aprovechar las nuevas funciones.

3.1.1 Por apt-get

Ejecutar el comando:

$ sudo apt-get install eclipse

Podrá iniciar Eclipse a través del menú o de la consola:

$ eclipse

3.1.2 Descargar de la pagina web

Primero hay que instalar las dependencias que son –como mínimo– Java 6:

$ sudo apt-get install sun-java6-jdk

Descargar Eclipse Classic desde su página web. Seleccionar la carpeta donde se instalará:

$ cd ~/bin
$ tar xvzf ~/Descargas/eclipse-SDK-3.7.1-linux-gtk-x86_64.tar.gz
$ cd eclipse
$ ./eclipse

Es necesario intercambiar Descargas/eclipse-SDK-3.7.1-linux-gtk-x86_64.tar.gz por la versión y la carpeta adecuada.

3.2 PyDev

PyDev es un plug-in para Eclipse que facilita la programación en Python.

3.2.1 Instalación

Se instala PyDev desde el propio Eclipse. En Eclipse elige [Help] y en el menú que aparece Install New Software….

En la ventana que aparece ingresar en el campo Work with:http://pydev.org/updates y seleccionar Add….

http://www.domatix.com/wp-content/uploads/install_work_with_pydev.png

Ingresar ‘http://pydev.org/updates’ y seleccionar ‘Add…’

Aparecerá una nueva ventana donde se ingresa un nombre y seleccionar OK.

http://www.domatix.com/wp-content/uploads/add_repository.png

Ingresar un nombre y hacer clic en ‘OK’.

Aparece Pending en la lista hasta que haya cargado la información. Después se verán dos nuevas entradas:

  1. PyDev
  2. PyDev Mylyn Integration (optional)

Seleccionar PyDev y seleccionar Next.

http://www.domatix.com/wp-content/uploads/install_pydev_selected.png

Seleccionar ‘PyDev‘ y seleccionar ‘Next’

En el siguiente menú seleccionar PyDevfor Eclipse y hacer click en Next.

http://www.domatix.com/wp-content/uploads/install_pydev_selected.png

Seleccionar ‘PyDev for Eclipse’ y hacer clic en ‘Next’.

Aparece el menú Review Licenses. Para continuar es necesario aceptar las condiciones y terminos de la licencia de uso, seleccionar I accept the terms of the
license agreement
y hacer clic en Finish.

http://www.domatix.com/wp-content/uploads/install_license_agreement.png

Aceptar la licencia y hacer click en  Finish.

Aparecerá una nueva ventana que indicará el proceso de la instalación.

http://www.domatix.com/wp-content/uploads/installing_software.png

Mientras está instalando, desea saber si se confía en el certificado de Aptana. Seleccionar Aptana Pydev; Pydev;Aptana, en esa misma ventana y luego hacer clic en OK.

http://www.domatix.com/wp-content/uploads/selection_needed.png

Seleccionar ‘Aptana’ y hacer clic en ‘OK’

Después de haber instalado PyDev Eclipse se requiere reiniciar para poder usar el nuevo plugin. Hacer clic en Restart Now.

http://www.domatix.com/wp-content/uploads/restart_now.png

Hacer clic a ‘Restart Now’

3.2.2 Configuración

En la ventana principal de Eclipse, seleccionar [Window] y seleccionar Preferences. Se abre una nueva ventana donde se localiza el punto PyDev, y seleccionar el subpunto Interpreter - Python. Hacer click en AutoConfig.

http://www.domatix.com/wp-content/uploads/pydev_config.png

Configuración de PyDev

Si no existen errores, en la ventana siguiente se tiene que comprobar la selección que ha hecho Eclipse.

http://www.domatix.com/wp-content/uploads/pydev_config_selection.png

Comprobar la selección de Eclipse.

Hacer click en OK.

3.3 Soporte para XML

Instalaremos otro plugin que facilita el trabajo con archivos XML. El proceso es similar al de PyDev.

3.3.1 Instalación

Seleccionar de nuevo [Help] y Install New Software….Es nedesario abrir el menú Work with: y elegir Indigo – http://download.eclipse.org/releases/indigo (el nombre puede cambiar según la versión de Eclipse que se este usando) y de la lista seleccionar el punto Web, XML and Java EE Development y selecciones Eclipse XML Editors and Tools. Hacer clic en Next.

http://www.domatix.com/wp-content/uploads/install_xml_editor.png

Seleccionar ‘Eclipse XML Editors and Tools’.

Proceder como en la instalación de PyDev aceptando la licencia y reiniciando Eclipse después de la instalación.

3.4 OpenERP Templates

Los templates se pueden descargar directamente o via svn:

$ sudo apt-get install subversion
$ svn checkout 
       http://openerp-eclipse-template.googlecode.com/svn/trunk/ 
       openerp-eclipse-template-read-only

Explicación de la instalación y el uso de los snippets en unos vídeos en Youtube:

Para importarlos:

3.4.1 Python Snippets

  • [Window] -> Preferences, PyDev -> Editor -> Templates,
  • Hacer click en  Import y
  • Seleccionar el  archivo templates-openerp.xml.

3.4.2 XML Snippets

  • [Window] -> Preferences, XML -> XML Files -> Editor -> Templates,
  • Hacer click en Import
  • Seleccionar  el archivo Openerp-eclipse-xml-template.xml.