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

Responsive web design (RWD)

El objetivo de las páginas web “responsive” es facilitar la navegación, usabilidad y lectura, ajustando los contenidos sin reducir el tamaño, es decir, reubicando los elementos de la propia web según el tamaño del área de visionado del cliente web.

Las principales características de un diseño web “responsive” son:

  • Visualización optimizada en todos los dispositivos, smartphones y tablets
  • Experiencia de usuario óptima
  • Optimización de la velocidad de carga para dispositivos más pequeños
  • Optimización de motor de búsqueda para dispositivos más pequeños
  • Gestión del mismo código, archivos y administración para todos los dispositivos

Responsive Design Web

Si desea que una web muestre el mismo contenido en dispositivos más pequeños, el diseño “responsive” es el camino a elegir. Las plantillas “móviles” para web están extremadamente limitadas o son versiones recortadas del sitio web completo, ocultando muchas partes del mismo y sesgando la experiencia de navegación del usuario.

Además, utilizando diseños “responsive”, la gestión del código base y aspecto será la misma para todas las visualizaciones. No hay que olvidar que actualmente hay 5 mil millones de dispositivos móviles, y cada vez es más usual navegar en este tipo de pantallas.

Algunos recursos interesantes para comenzar con RWD:

Para testear el aspecto de una web en diferentes tamaños: MattKersleyresizeMyBrowser, ScreenFly, Responsivepx.

Algunas herramientas adicionales:

Actualización: Una preview de lo que será la versión 3.0 de Joomla, de la mano de Joomshine: http://joomla30.joomlashine.com/

Finalmente también vale la pena darse una vuelta por el proyecto Bootstrap, desarrollado por los ingenieros de Twitter y actualmente disponible en GitHub. Y algunos recursos para Bootstrap.

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.

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

2 OpenERP

2.1 Instalación de dependencias

Es necesario instalar algunos paquetes de los cuales depende OpenERP.

2.1.1 Dependencias del servidor de OpenERP

Como se encuentra documentado en esta sección.

$ sudo apt-get install python-lxml python-mako python-dateutil 
 python-psycopg2 python-pychart python-pydot python-tz 
 python-reportlab python-yaml python-vobject python-ldap 
 python-libxslt1

2.1.2 Dependencias del cliente OpenERP

Como se encuentra documentado en esta sección:

$ sudo apt-get install python-gtk2 python-glade2 python-matplotlib 
 python-egenix-mxdatetime python-dateutil python-lxml python-tz 
 python-hippocanvas python-pydot

2.1.3 Dependencias del cliente web de OpenERP

La documentación se encuentra en esta sección:

$ sudo apt-get install python-cherrypy3 python-formencode 
 python-babel

2.2 Instalar OpenERP desde Launchpad

2.2.1 Instalar Bazaar

Para instalar OpenERP desde Launchpad es necesario utilizar Bazaar:

$ sudo apt-get install bzr

2.2.2 Grabar el código

Para este paso existen dos opciones:

  1. Grabar y ejecutar este pequeño script que hemos desarrollado en Domatix
  2. Hacerlo a manualmente:

Ir a la carpeta donde se requiere tener la instalación de OpenERP – usualmente se instala en una carpeta con el nombre: “openerp” en la carpeta del usuario:

$ PATH_TO_OPENERP=~/openerp
$ mkdir $PATH_TO_OPENERP
$ mkdir $PATH_TO_OPENERP/server
$ cd $PATH_TO_OPENERP/server
$ bzr branch lp:~openerp/openobject-server/6.0 6.0
$ bzr branch lp:~openerp/openobject-server/5.0 5.0
$ mkdir $PATH_TO_OPENERP/client
$ cd $PATH_TO_OPENERP/client
$ bzr branch lp:~openerp/openobject-client/6.0 6.0
$ bzr branch lp:~openerp/openobject-client/5.0 5.0
$ mkdir $PATH_TO_OPENERP/client-web
$ cd $PATH_TO_OPENERP/client-web
$ bzr branch lp:~openerp/openobject-client-web/6.0 6.0
$ bzr branch lp:~openerp/openobject-client-web/5.0 5.0
$ mkdir $PATH_TO_OPENERP/addons
$ cd $PATH_TO_OPENERP/addons
$ bzr branch lp:~openerp/openobject-addons/6.0 6.0
$ bzr branch lp:~openerp/openobject-addons/5.0 5.0
$ mkdir $PATH_TO_OPENERP/addons-extra
$ cd $PATH_TO_OPENERP/addons-extra
$ bzr branch lp:~openerp-commiter/openobject-addons/extra-6.0 6.0
$ bzr branch 
 lp:~openerp-commiter/openobject-addons/stable_5.0-extra-addons 5.0

Para que los ‘addons’ funcionen en la versión 5.0 hay que hacer unos links:

$ cd $PATH_TO_OPENERP/server/5.0/bin/addons
$ for d in $PATH_TO_OPENERP/addons/5.0/*; do ln -sv $d; done

En la versión 6.0 hay que configurarlo a través del archivo ~/.openerp_serverrc. Si no existe este archivo en el sistema iniciar el servidor de la siguiente manera:

$ cd $PATH_TO_OPENERP/server/6.0
$ bin/openerp-server.py --save --stop-after-init

Abre el el archive ~/.openerp_serverrc en tu editor preferido y modifica la linea

addons_path = /your/path/to/openerp/server/6.0/bin/addons

A algo como lo siguiente:

addons_path = /your/path/to/openerp/server/6.0/bin/addons,/your/path/to/openerp/addons/6.0

2.3 Comprobar que funciona.

2.3.1 El servidor

Esto solo funcionará si se ha creado anteriormente la base de datos para testificar.

$ cd $PATH_TO_OPENERP/server/6.0
$ bin/openerp-server.py --db_user=openerp

2.3.2 El cliente

Con el servidor arrancado es posible iniciar el cliente:

$ cd $PATH_TO_OPENERP/client/6.0
$ bin/openerp-client.py

Aparece una ventana para hacer el login. Como clave se ingresa: demo.

La clave es ‘demo’

Si todo ha sido correcto, ahora hay un cliente conectado.

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

Si todo ha sido correcto…

Se puede observar en la pantalla donde se ha iniciado el servidor para verificar si ha ocurrido algún error.

2.3.3 El interfaz de web

$ cd $PATH_TO_OPENERP/web 
$ ./openerp-web.py

En el navegador local hay que abrir la pagina http://192.168.0.122:8080. El usuario y clave es demo. Después, hacer clic en Login.

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

Usuario ‘demo’, clave ‘demo’.

Si todo ha sido correcto se verá una ventana así:.

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

Si la instalación ha sido correcta…

2.3.4 Eliminar la base de datos ‘testerp’

Ahora que se ha comprobado que todo funciona correctamente, procedemos a eliminar la base de datos que se ha creado anteriormente:

$ sudo su - postgres
postgres $ psql
psql (9.1.2)
Type "help" for help.
postgres=# DROP DATABASE testerp;
DROP DATABASE
postgres=# q
postgres@vincebox ~ $ exit

Oferta de trabajo en Valencia – Programador web

– conocimientos html5, css, mysql, php, javascript
– experiencia con CMS (Joomla) y tiendas online (Magento y PrestaShop)
– administración sistemas GNU/Linux
– se valorarán conocimientos sobre plataformas virtualización (proxmox, kvm) y SEO
– experiencia en desarrollo con herramientas de control de versiones (GIT, Launchpad)
– imprescindible realizar todas las tareas con GNU/Linux y software libre (ubuntu, debian, eclipse…)
– se valorarán conocimientos de Django y Python
– se valorará participación en comunidades de software libre (traducción, localización..)

Se ofrece:

Incorporación inmediata en Domatix. El trabajo se realizará en nuestras oficinas de Valencia, en horario comercial, con una dinámica flexible y variable. La retribución económica será acorde con los conocimientos y experiencia del candidato.

Enviar currículums a info(a)domatix.com.

Installing Zoook on Ubuntu – Part IV: Zoook – Parametrize and connect with OpenERP

1. Install OpenERP dependencies

You’ll have to install the following modules in OpenERP:

2. Connecting Zoook to the Database

At first create a PostgreSQL database for Zoook. In a development environment you can use the user openerp. This way you don’t have to create a new one. In production its recommended to make sure that every user has an exclusive access to the database.

$ sudo -u postgres psql
postgres=# CREATE DATABASE dj_zoook OWNER openerp;
postgres=# l

The last command shows the existent databases. If everything worked out fine it should show someting like the following:

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

Verify the correct creation of the database.

3. Parametrisation of Zoook

3.1. ~/django-projects/zoook-app/config.py

Edit the file and adjust the parameters of the connection to OpenERP. You’ll have to configure all passages. The following ones are especially important for the interconnection with the OpenERP server and error detection:

  • LANGUAGESDefines the languages of your web shop. They have to be the same as in OpenERP.
    #Edit your languages
    LANGUAGE_CODE = 'es'
    LANGUAGES = (
        ('es', ugettext('Spanish')),
        ('en', ugettext('English')),
    )
    DEFAULT_LANGUAGE = 1
    LOCALE_URI = True
  • OERP_SALEIndicates which OpenERP shop should be used in Zoook (just for the case that you have several shops).
    OERP_SALE = 1 #Sale Shop. All price, orders, ... use this Sale Shop ID.
  • LOGSDefines the path to Zoooks logging files.
    LOGFILE = '/home/roberto/django-projects/zoook-app/log/sync.log' #path sync log
    LOGSALE = '/home/roberto/django-projects/zoook-app/log/sale.log' #path sale log
  • DATABASESDefines where and how Zoook finds its database.
    DATABASES = {
        'default': {
            'ENGINE': 'django.db.backends.postgresql_psycopg2', # Add 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
            'NAME': 'dj_zoook',     # Or path to database file if using sqlite3.
            'USER': 'openerp',      # Not used with sqlite3.
            'PASSWORD': 'openerp',  # Not used with sqlite3.
            'HOST': '192.168.0.122',    # Set to empty string for 192.168.0.122. Not used with sqlite3.
            'PORT': '5432',         # Set to empty string for default. Not used with sqlite3.
        }
    }
  • OERP_CONFDefines the connection to the XML-RPC service of OpenERP.
    OERP_CONF = {
        'username':'admin',
        'password':'openerp',
        'dbname':'openerp',
        'protocol':'xmlrpc', #xmlrpc
        'uri':'http://192.168.0.122', #xmlrpc
        'port':8069, #xmlrpc
    # 'protocol':'pyro', #pyro
    # 'uri':'192.168.0.122', #pyro
    # 'port':8071, #pyro
    }

3.2. ~/django-projects/zoook-app/sync/config_path.py

Contains the routes to Zoook so that the SSH synchronisation process can find the needed files.

djpath = '/home/roberto/django-projects/zoook-app'

3.3. ~/django-projects/zoook-app/settings.py

Edit this file to assign a new unique password to Zoook. I’d recommend to use a password generator such as safepasswd.com.

# Make this unique, and don't share it with anybody.
SECRET_KEY = 'YOUR_PASSWORD_GOES_HERE'

3.4. Create Zoooks database tables

  • Generate the data base structure
    $ cd ~/django-projects/zoook-app
    $ python manage.py syncdb

    The script will ask if you want to create a new super-user. Affirm and pass it the needed data for the account you’ll later want to administer Zoook with.

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

    Create a superuser for Django.

3.5. ~/django-projects/zoook-app/configuration.py

Execute the configuration assistant and give it further information needed by Django.

  • Execute configuration.py
    $ cd ~/django-projects/zoook-app
    $ ./configuration.py

    The output should look like this:

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

    Configuration of Django.

3.6. Adjust file permissions

  • Change the permissions in the sync directory
    $ cd ~/django-projects/zoook-app/
    $ sudo chown -R roberto:www-data *
    $ sudo chmod 775 -R sync

3.7. Testing Zoook

  • Run the server
    $ cd ~/django-projects/zoook-app/
    $ python manage.py runserver

    this should show something like:

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

    Successfully initiated Django server.

    Open your browser and open up the direction of the server (http://127.0.0.1:8000/). Zoook should load the first time and you should end up with a site like this:

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

    Start page of Zoook.

    Access the administration area with the super user credentials created beforehand:

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

    Zooks administration page.

4. Connecting Zoook with OpenERP

A SSH server is required on the machine where Zoook is installed:

$ sudo apt-get install openssh-server

The next step is to configure poweremail to create a template for orders. This article won’t cover the further details of this step. You can get that information here.

Now, open up OpenERP and configure the shop for the connection with Zoook. Open

Sales => Configuration => Sales => Shop

Choose the shop you’re going to use with Zoook, edit it and check the box next to OpenERP e-Sale in the upper right. As an outcome of this should appear a new configuration tab for Zoook.

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

Mark a shop fort exportation.

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

Mark all products for exportation.

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

Configure the SSH connection.

When doing the test of the connection it should pop up a message, saying that it is configured properly.

5. Export test products

Now, we’ll only have to add some test categories and products. The only thing noteworthy at this point is that in order to export a product to the web you have to check “Export to online shop?”. Once this is checked you’ll see a new tab with the name “e-Sale” where you can parametrise the options of the product of the web shop.

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

Configuring e-Sale options on a product.

After the creation of products you’ll have to go back to the configuration of the shop to export products, categories, images etc. After doing a refresh of the page of Zoook you should be able to see the introduced data:

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

Successfully exported category in Zoook.

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

Successfully exported product in Zoook.