Nuevo proyecto de ZOOOK esale

Instalación de Django y ZOOOK

ZOOOK es una aplicación de Django, pero no es compatible con la versión 1.5, por lo que lo primero que habrá que hacer es instalar la versión 1.4. Se puede instalar ejecutando:

$ sudo pip install django==1.4

En el manual anterior se instalaban todas las dependencias de forma manual, en este se va a utilizar el instalador del proyecto para instalar todas las dependencias. Para descargar e instalar el proyecto:

$ bzr branch lp:zoook-esale/6.1 django-zoook
$ cd django-zoook
$ sudo python setup.py install

Para poder ejecutar ZOOOK será necesario crear la base de datos con su acceso y configurarlo, para que Django cree los datos necesarios.

Se crea el usuario con acceso a la base de datos:

$ sudo -u postgres createuser --createdb --no-superuser --no-createrole --pwprompt zoook

Se crea la base de datos para este usuario:

$ sudo -u postgres psql -d postgres
postgres=# CREATE DATABASE dj_zoook OWNER zoook;
postgres=# q

Por último habrá que configurar ZOOOK, para esto hay que editar el fichero config.py.

Indicar la base de datos:

DATABASES = { 
 'default': { 
 'ENGINE': 'django.db.backends.postgresql_psycopg2', 
 'NAME': 'dj_zoook', 
 'USER': 'zoook', 
 'PASSWORD': 'zoook', 
 'HOST': '192.168.0.122', 
 'PORT': '5432', 
 } 
}

La configuración de OpenERP:

OERP_CONF = { 
 'username':'admin', 
 'password':'admin', 
 'dbname':'openerp', 
 'protocol':'xmlrpc', #xmlrpc 
 'uri':'http://192.168.0.122', #xmlrpc 
 'port':8069, #xmlrpc 
}

En el fichero de configuración se indica la posibilidad de utilizar pyro, pero esta opción no está disponible en OpenERP 6.1

Se puede configurar los idiomas para la web:

LANGUAGE_CODE = 'es' 
LANGUAGES = ( 
 ('en', ugettext('English')), 
 ('es', ugettext('Spanish')), 
) 
DEFAULT_LANGUAGE = 1 
LOCALE_URI = True 
LOCALEURL_USE_ACCEPT_LANGUAGE = True 
LOCALES = { 
 'en':'en_US', 
 'es':'es_ES', 
}

En la configuración se indica también la o las tiendas de OpenERP a las que tiene acceso la web, se indica el identificador interno.

OERP_SALE = 1 #Sale Shop. All price, orders, ... use this Sale Shop ID. 
OERP_SALES = [1] #Sale Shops. Orders by Sale Shops

Por último se puede indicar la configuración para el envío de correos

EMAIL_USE_TLS = True 
EMAIL_HOST = 'smtp.gmail.com' 
EMAIL_HOST_USER = 'myemailuserXXX' 
EMAIL_HOST_PASSWORD = 'mypasswordXXX' 
EMAIL_PORT = 587

Antes de ejecutar por primera vez la aplicación será necesario crear el fichero de log y configurarlo.

Se puede crear por ejemplo, dentro de la carpeta django-zoook principal del proyecto, un directorio para log con un fichero zoook.log

$ mkdir log
$ touch log/zoook.log

En el fichero logconfig.py se indicará donde se encuentra este fichero en esta linea

LOGFILE = os.path.join(zoook_root, 'log', 'zoook.log') #path sync log

Una vez está todo configurado se pueden crear las tablas en la base de datos necesarias para ejecutar la web.

$ python manage.py syncdb

La primera vez que se ejecute syncdb creará un usuario de administración para Django, habrá que indicar el nombre de usuario y su contraseña.

Antes de arrancar la web habrá que configurar la tienda con:

$ ./configuration.py

Por ultimo se arranca la web con:

python manage.py runserver

En caso de error puede ser debido a la falta de algún módulo de django, se puede comentar en settings.py o instalarlo con pip.

Instalación de ZOOOK en OpenERP

Se instalará ZOOOK sobre OpenERP 6.1.

Para facilitar la instalación se han creado nuevos repositorios, uno con el propio ZOOOK y otro con los addons extra necesarios.

Para descargar los repositorios:

$ bzr branch lp:~zoook-community/zoook-esale/zoook-6.1 
$ bzr branch lp:~zoook-community/zoook-esale/zoook-extra-addons-6.1

La instalación de ZOOOK en OpenERP será igual que cualquier otro módulo, añadiendo los módulos descargados al addons_path, y desde el propio OpenERP actualizando la lista de módulos disponibles e instalando el módulo zoook. Importante al añadir en el archivo de configuración el extra-addons de zoook hacerlo antes del extra-addons genérico, con esto se consigue cargar los módulos de zoook antes.

Configuración de ZOOOK en OpenERP

Una vez instalado el módulo en Ventas/Configuración/Ventas/Tienda podemos configurar los parámetros de la tienda que se quiera sincronizar con ZOOOK.

zoook-OpenERP-01-tienda

Al marcar la opción OpenERP e-sale se podrán configura el resto de parámetros.

La conexión SSH será necesaria para sincronizar ZOOOK

En la solapa de acciones están los procesos para actualizar zook, exportar categorías, productos, imágenes y configuración global.

Para exportar el árbol de categorías, se indicará la categoría raíz en la solapa configuración y habrá que marcar como exportable cada categoría.

¿Cuanto cuesta un OpenERP? (o una casa)

La mayoría de los implantadores con experiencia de OpenERP en España tenemos un ‘paquete’ básico con los módulos oficiales y la localización española, e incluso un servicio saas, para comenzar a utilizar OpenERP invirtiendo una cantidad muy pequeña y comenzar así a amortizarlo cuanto antes. Dicho paquete se puede enriquecer adquiriendo bonos de horas para todas aquellas parametrizaciones que la empresa vaya requiriendo.

Estas soluciones, suficientes para la mayoría de empresas pequeñas, pueden no serlo para otras, conscientes (o no) de que van a requerir adaptaciones para adecuarla a su sector o a sus necesidades específicas.

Para conocer y presupuestar correctamente una implantación de cierta magnitud de OpenERP (y cualquier ERP), es necesario realizar un análisis de requerimientos. Elaborar dicho documento requiere invertir tiempo y recursos, que son repercutidos al cliente final, y hasta no realizar el documento final, el cliente no conocerá el desglose de los costes de su implantación.

«Es necesario un análisis de requerimientos antes de implantar»

Este procedimiento choca con algunas empresas, que se encuentran con el dilema de que un OpenERP con módulos oficiales de salida no le resulta suficiente, pero sin la experiencia de haber realizado implantaciones de ERPs anteriormente, nos devuelven todo lo explicado anteriormente en forma de pregunta: ¿De verdad que tengo que pagar por un presupuesto para mi empresa?

Para simplificar la explicación, vamos a referirnos a una conocida licencia literaria: la metáfora. Supongamos que OpenERP es una casa.

¿Cuanto cuesta una casa?

La respuesta media sería: «depende«. Podemos hacer media entre la más cara y la más barata, pero difícilmente ese precio va a ajustarse a lo que nosotros queremos comprar. Hay casas para todos los gustos y bolsillos, de alquiler y venta, en el centro de la ciudad o en las afueras, etc…
Si ninguna de las casas, apartamentos, adosados o resto de edificaciones ‘prefabricadas’ resuelve el 100% de las necesidades del comprador, o se desea construirla desde cero, es necesario contratar a un arquitecto que realice un plano. El coste de dicho plano es independiente del coste de la construcción, aunque es requerido para realizarla. Y se hace en todo momento teniendo en mente las necesidades y un presupuesto aproximado. Con el coste final ‘real’ en mano, se pueden plantear cambios con el arquitecto para ampliar, reducir o eliminar algunas estancias, o simplemente prepararlas para finalizar más adelante, en función al presupuesto asignado, el tiempo de ejecución y las prioridades de necesidades.

Lo correcto sería pues plantear ¿Que presupuesto aproximado tiene usted para comprar su casa? Y en función de la respuesta estudiar las posibilidades.

Pues bien, este plano de arquitecto es el equivalente a nuestro análisis de requerimientos.

Analizar y ‘diagnosticar’ las necesidades de una empresa para orientar una implantación de un ERP es una tarea que debe ser realizada por un equipo profesional y con experiencia. El análisis ya tiene un valor per se, que muestra, detalla y desglosa cada una de las áreas funcionales (no cubiertas de serie por el ERP) en un documento, único y diferente para cada empresa. Ya entra dentro del ámbito de adaptación de la empresa si se decide realizar cambios en la metodología de algunos procesos para adaptarse al ‘estándar’ o si es preferible modificar el ERP para ajustarlo a sus procesos. Lo habitual es llegar a un consenso y dejarse aconsejar por el consultor externo. El análisis es una hoja de ruta, validada por implantador y cliente, cuyos hitos se pueden alcanzar en una o varias fases, nuevamente dependiendo de las necesidades y presupuesto de la empresa.

Aquellos que solicitan presupuesto sin tener una asignación de recursos (no sólo económicos, de personal interno y tiempo) preparada para la implantación es probable que no la finalicen con éxito. Nadie conoce mejor la empresa y sus necesidades que su plantilla, por lo que solicitar un presupuesto sin haber siquiera descrito dichas necesidades al implantador es una manera muy arriesgada de comenzar el cambio. Implantar un ERP no es cambiar la web, o el tríptico comercial de la empresa, no hay margen de error en una herramienta que gestiona todos los procesos y a todos los departamentos de una empresa.

presupuesto-openerp

No obstante, antes de contactar con el proveedor para el cambio de ERP (o la implantación de uno nuevo), debería requerirse la reunión interna de todos los departamentos y la elaboración de uno o más documentos con la descripción de los procesos de trabajo y áreas funcionales de la empresa. Esto facilita la elaboración de una estimación aproximada pre-análisis, que pueda indicar a groso si los números van a cuadrar.  Un consejo: minimice las ‘sorpresas’ entre la elaboración de dicho documento y el análisis de requerimientos definitivo para no ver grandes diferencias entre el precio pre-análisis y post-análisis.

Una mención a la metodología (aunque dicha área merece uno o varios más artículos adicionales), en forma de 7 claves para una implantación exitosa:

  1. Personal involucrado e integrado
  2. Sufiente aportación de los usuarios
  3. Especificaciones correctamente definidas
  4. Expectativas realistas y fijadas
  5. Presencia de un consultor externo
  6. Buena comunicación
  7. Metodología de implantación clara

(extraído de http://www.slideshare.net/domatix/presentacion-openerp-domatix)

Conclusión

Por tanto, por favor, no se extrañe en el caso de que su implantador, ante una falta de información suficiente sobre su implantación, le envía un presupuesto para realizar el análisis de requerimientos. O le pregunte directamente cual es su presupuesto aproximado para la implantación.

Inténtalo con OpenERP.

Vender es crítico pero también lo es gestionar correctamente a tu cliente, facturarle, cobrar, manejar la relación con tus proveedores, negociar precios, conocer tu tesorería, tus costes, beneficios/pérdidas, organizar las tareas de tus empleados. En definitiva… liderar tu negocio. Si no imposible, es bastante complicado que hagas esto de forma eficiente utilizando sólo el correo electrónico y la ofimática. Mientras tengas poco volumen, podrás gestionarlo pero si de verdad funciona… te verás inmersa en un mar de papeles, carpetas, descontrol y stress que incidirá directamente en la atención a tu cliente o en la calidad de tu servicio. Evitalo. Implanta un sistema de gestión integral. Prevé que tu negocio va a funcionar y haz que el crecimiento no te pare. Hasta hace bien poco, no existían sistemas de este tipo a un precio asequible y mucho menos en software libre, donde no pagas licencias. Ahora es posible. Optimiza el tiempo que dedicas a realizar «lo aburrido» inherente a cualquier negocio. Evita duplicar datos y realizar tareas repetitivas y sin valor añadido. Aprovecha ese tiempo que pierdes para aprender a gestionar tu negocio de forma efectiva y eficiente. Infórmate de las alternativas que existen y selecciona la más adecuada. Y si tienes dudas… pregunta.

Inténtalo con OpenERP.

Extraido de http://www.openerpsite.com/openerp-empresa-gestion-erp/

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».

Envío de emails automáticos desde OpenERP 6.1

Configuración del servidor de correo

OpenERP utiliza conexión SMTP para el envío de correos, para configurarlo hay que entrar en /Settings/Configuración/Email/Outgoing Mail Servers. Por defecto aparece configurado el servidor local, si no está configurado un servidor de correo en la misma maquina que está el servidor de openerp se puede modificar esta entrada. También se podrían configurar varios servidores de correo por si falla uno de ellos.

bootswatch-bootstrap

En la siguiente captura se puede ver como se ha configurado para usar una cuenta smtp.

bootswatch-bootstrap

Haciendo clic en el botón «Test Connection» se puede comprobar si está configurado correctamente.

No enviar correos a todos los clientes

En la versión 6.1 de OpenERP se envían correos a todos los clientes, para configurar por defecto a un cliente que no se le envíen correos se hace desde la propia ficha del cliente. En la solapa Ventas y Compras está el campo «Opt-out», si dicho campo se marca, no se enviarán correos automáticamente.

bootswatch-bootstrap

Si por defecto se quiere que no se envíen correos a todos los clientes se puede hacer al configurar un cliente marcando el valor por defecto de Opt-out como activo. Con esto, los nuevos clientes que se creen tendrán el campo Opt-uot marcado por defecto.

Para asignar valores por defecto en el cliente web de OpenERP 6.1 se puede hacer clickando en la entrada /Personalizar/Establecer por defecto de la columna derecha y seleccionando el campo que quieres establecer por defecto.

bootswatch-bootstrap

Envío de correos en el idioma asociado a la empresa

Si no se configura la plantilla de envío de forma correcta, se enviará a todos los clientes en inglés. Para hacer que se envíe en el idioma del cliente habrá que configurar la plantilla en /Settings/Configuración/Email/Plantillas y poner en el campo Language Selection el valor del idioma de la empresa asociada al documento, en el caso de pedido de ventas:
${object.partner_id.lang}

bootswatch-bootstrap

En la misma plantilla también habrá que añadir las traducciones a los idiomas que necesitemos. Los campos que admiten traducciones aparecen con un icono específico (mostrado en la siguiente captura) y al clickar sobre el icono mostrarán el formulario de traducciones.

bootswatch-bootstrap

En este ejemplo se muestran las traducciones únicamente al español, si hubiesen mas idiomas en el sistema aparecerían en mas columnas.

bootswatch-bootstrap

Al escribir las traducciones hay que tener en cuenta lo que son textos a traducir y lo que son campos calculados por OpenERP o parámetros de control.

Bootstrap

Bootstrap surge con la pretensión de superar este obstáculo otorgando a los desarrolladores una base sobre la que trabajar y definir un marcado estándar para ciertos elementos de una página web, a la par que proporcionar un diseño responsive (tan de moda últimamente, como comentábamos en un artículo anterior), capaz de acoplar éste a cualquier resolución de pantalla y dispositivo móvil.

Sí que es cierto que el estilo de todos estos elementos, tan limpio y entendible para el usuario, es más idóneo para interfaces de administración que para el front-end de una página web, pero siempre es posible añadir reglas propias de estilo en un fichero aparte para adaptarlo a aquél que nos venga impuesto desde arriba por un PSD o por el propio equipo de diseño.

Para mejorar esta experiencia en el front-end, también surgen proyectos como el de Bootswatch, que dispone de varias plantillas para extender el estilo base de Bootstrap.

bootswatch-bootstrap

Bootstrap básicamente se compone de un conjunto de ficheros CSS de mínimo peso (6Kb comprimidos) que podemos añadir a la cabecera de nuestra página web para comenzar a utilizar. Una vez añadidos, la idea es definir el grid (para marcar el diseño responsive) y el marcado de los elementos que deseemos utilizar. Tenemos gran cantidad de documentación al respecto en la página oficial de Bootstrap.

Una muestra de la extensión de este framework es que la siguiente versión de Joomla, la 3.0., disponible a priori en septiembre de este mismo año, implantará internamente Bootstrap. Esto significa que algunos de los módulos del núcleo de Joomla cambiarán su marcado para acoplarse al marcado definido por Bootstrap. A nivel de plantillas, esto no debería suponer un gran cambio para aquellas que provengan de la versión 2.5. de Joomla. En el siguiente enlace está disponible una demo de esta nueva versión de Joomla que está por llegar para que vayamos abriendo boca.

En el intento de integrar Bootstrap con Joomla, uno de los proyectos más interesantes disponibles en la red es Joostrap. Joostrap dispone de un catálogo de plantillas base listas para integrar en una página web que utilice Joomla. Desde Domatix hemos estado testeando una de estas plantillas para comprobar cuán efectiva es su integración en dicho gestor de contenidos (algunos de nuestros próximos retos son comprobar la integración de la responsividad en WordPress y Prestashop). Algunas de las conclusiones a las que hemos podido llegar son:

•  Al ser Bootstrap un software en fase de desarrollo, su implantación todavía está algo verde y, en ocasiones, aparte de la documentación oficial, la integración en un CMS carece de una documentación sólida con la que poder comenzar a trabajar.

•  Deben modificarse a mano algunas de las plantillas de los principales módulos de Joomla, como por ejemplo las plantillas del famoso módulo K2, para acoplarlas al marcado de Bootstrap.

•  Bootstrap utiliza como base las librerías Jquery y nuestra experiencia es que, al usar Joomla como base la librería Mootools, se han tenido que aplicar algunos arreglos todavía no muy bien documentados para que ambas fueran compatibles. La nueva versión de Joomla incluirá Jquery y permitirá la convivencia de ambas librerías, por lo que esperamos que esta compatibilidad sea mayor y con ello la documentación disponible al respecto.

bootswatch-bootstrap

Turnkey Appliance para Tryton ERP

Como base hemos utilizado Turnkey LAPP que viene con Linux, Apache, PostgreSQL, PHP, Python y Perl. Usamos esta appliance por sus herramientas de configuración web Webadmin y PHPPgAdmin. Aunque no lo hemos probado, debería funcionar también sin problema con Turnkey PostgreSQL.

El parche se ha publicado en el wiki de desarrollo de Turnkey Linux y está disponible para su descarga en su foro.

Para aplicar el parche sobre la imagen de Turnkey LAPP es necesario utilizar TKLPatch. TKLPatch es el SDK que permite modificar las imágenes Turnkey. La aplicación del parche es muy sencilla pero primero es necesario instalar TKLPatch.

Para instalar TKLPatch se puede seguir la documentación publicada en su web, en Ubuntu la instalación desde repositorios no funciona correctamente pero desde el código se instala sin problemas, simplemente ejecutando:

apt-get install squashfs-tools genisoimage tar gzip git
git clone git://github.com/turnkeylinux/tklpatch.git
cd tklpatch
make install

Una vez instalado TKLPatch hay que descargar la imagen de Turnkey LAPP de:

http://www.turnkeylinux.org/download?file=turnkey-lapp-11.3-lucid-x86.iso

descargar el archivo de:

http://cdn.turnkeylinux.org/files/attachments/tryton-on-lapp.tar.gz

y ejecutar:

sudo tklpatch turnkey-lapp-11.3-lucid-x86.iso tryton-on-lapp.tar.gz

esto generará el fichero turnkey-lapp-11.3-lucid-x86-patched.iso listo para usar.

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.