Entradas

Publicado el

Correo-e inesperado de Openbravo

El otro día os contaba que Openbravo me había aceptado un parche, pues esta tarde he recibido un correo-e de Eduardo Argal, empleado de Openbravo, relacionado con el mismo. El correo-e es el siguiente.

 

Hola Cheli,

Te escribo para darte las gracias por el patch adjunto al issue «20038: Create Lines From in Sales invoices doesn’t set taxamt and taxbaseamt fields properly».
Nos gustaría incluir el patch que tu adjuntas en el issue, pero como política interna necesitamos que firmes y nos envies una copia del siguiente documento:

http://wiki.openbravo.com/wiki/Contributor%27s_Guide#Legal_aspects

Se trata de un documento que cualquier contributor debe de firmar antes de que podamos publicar su código como parte de la distribución core de Openbravo ERP.

Espero tu respuesta, y gracias de nuevo por la contribución.

—
Atentamente,

Eduardo Argal

 

Lo que me pide es que ceda mis derecho de copia a Openbravo para integrar el parche dentro del core. Es una práctica muy extendida entre las empresas que desarrollan un producto con licencia libre, lo que quieren es seguir teniendo el control sobre el código y poder hacer cosas como relicenciarlo. Esto en principio no es malo pero podría suceder que Openbravo en algún momento relicenciara el core con una licencia privativa y que tu parche estuviera en ese código.

A mi esta política no me gusta e intento evitarla en lo posible, entonces ¿por qué voy a acceder a firmar el documento?. Pues porque este parche a mi ni me va ni me viene, corrige un bug en el core que hacía que uno de los desarrollos que hice para un cliente no funcionara correctamente en un caso concreto, cuando se utilizaba el botón «Copiar lineas de». Además si no se corrige y se integra en el core me va a tocar seguir manteniendo el fork que tuve que crear con mi parche y no quiero dedicar tiempo a eso, simplemente no me interesa.

 

Lo gracioso del tema es que después de todos los problemas que he tenido con la empresa Openbravo al final va a haber un pedacito de código mio en su core :D.

 

Cheli

Publicado el

Mi último recuerdo, el canto de este gallo

Fué el último día que la vi, entonces me dijo que mataría a ese pájaro porque no la había dejado dormir :D. Quise enviarle esta foto después para que viera al culpable pero siempre está muy ocupada, no la aceptó.

 

Gallo

 

Ahora cuando escucho cantar al gallo me acuerdo de ese día.

 

Cheli

Publicado el

Localización española para OpenERP 6.1

Como os prometí en este apunte os voy a explicar la instalación de los módulos de la localización para España de OpenERP 6.1. Lo primero que tenemos que hacer es obtener los módulos desde el repositorio de bazaar en Launchpad.

 

bzr branch lp:openerp-spain/6.1 openerp-spain61

 

Esta orden nos creará el directorio openerp-spain61 con los módulos. Una vez tenemos los módulos tendremos que parar el servidor y copiarlos al directorio addons del mismo.

 

service openerp stop

cp -R openerp-spain61 /usr/lib/pymodules/python2.7/openerp/addons

 

Si no sabemos cual es el directorio de addons de nuestro servidor lo podremos averiguar mirando el registro de arranque.

 

cat /var/log/openerp-server.log | grep "addons paths"

 

En este punto tenemos dos posibilidades, la primera consiste en arrancar el servidor pasándole como parámetro la opción --update=módulos, donde módulos son los módulos a actualizar separados por comas. Nosotros le pasaremos los módulos de la localización. La segunda consiste en entrar en OpenERP y pinchar en la opción «Settings», aquí pinchar en «Define default users preferences» y en la opción «Interface» elegir extended. Ahora ya podremos seleccionar la entrada del menú «Settings->Modules->Update Modules List».

Tanto si hemos elegido la primera como la segunda posibilidad ya podremos ver nuestros módulos, sólo queda instalarlos y listo.

 

Nota:

Estoy ofreciendo unos mini cursos de desarrollo en OpenERP por 200€.

 

Cheli

Publicado el

Vacaciones de Semana Santa

Ya se acabaron las vacaciones de Semana Santa y hay que volver al trabajo. La Semana Santa en poblaciones como Calpe marcan el inicio de la temporada veraniega. Hubo muchísima gente en estas vacaciones, muchísima en la playa, incluso bañándose, pero es que ayer fuí al paseo y aunque ya se ha ido todo el mundo sigue habíando mucha más gente que antes de las vacaciones.

 

Playa de Calpe

Playa de Calpe

Esperemos que este año la temporada sea muy buena porque realmente lo necesitamos.

Cheli

Publicado el

Openbravo aceptó mi parche

No se si os acordáis que hace algunas semanas abrí un par de parches en Openbravo. En el primero sugerí una solución por la simplicidad de la misma, y en el segundo envié el parche. Parece ser que han corregido el primer error, eso si, con matices, y han aceptado mi parche en el segundo.

 

0020015   ,  0020038

 

El primer error consistía en que un campo «booleano» (excluir retenciones en lineas de factura) que en Openbravo se representa como un char(1) en el que únicamente se permiten valores (‘Y’, ‘N’) permitía valor null. El problema es que al utilizar el método «Copiar lineas de», ese campo se ponía a null. Mi sugerencia fué que debía restringirse el valor a (‘Y’, ‘N’) y por tanto ser not null y que al utilizar este método se pusiera a ‘N’ por defecto en lugar de a null. La respuesta de Openbravo ha sido, vale, vamos a ponerlo a ‘N’ en lugar que a null al utilizar este método pero no vamos a añadir una restricción not null porque esto rompería nuestra API (entendiendo como API que un módulo de openbravo que haya puesto a null el valor de este campo incorrectamente igual que lo hacía el «Crear lineas de» se rompería al aplicar el cambio.

 

En el segundo error envié el parche, y este parece que lo han aceptado. Consistía en que no se calculaban los campos de base imponible para impuestos y impuestos en lineas de factura cuando se utilizaba la función «Crear lineas de». Lo que hice es que se aplicara el mismo cálculo de estos dos campos al ejecutar el proceso «Crear lineas de» que cuando se guardaba una linea de factura.

 

Estoy contento porque como ya comenté en mi anterior apunte Openbravo no suele aceptar correcciones o parches que no vengan de Partnes (que pagan). Yo estoy en contra de las políticas que ha tomado la emrpesa (empresa con modelo de negocio privativo con licencia del core libre para aparentar) y que creo que la están hundiendo. Pero bueno, esto demuestra que aceptan cosas externas y es de agradecer, ¿quizá se estén dando cuenta de su error?, error desde mi punto de vista claro.

 

Cheli

Publicado el

Instalación de OpenERP 6.1 en Debian / Ubuntu

El proceso para instalar OpenERP 7.0 es exáctamente el mismo.

La forma más sencilla de instalar OpenERP 6.1 en Debian / Ubuntu es a través del paquete disponible en la página de OpenERP. Lo primero que tenemos que hacer es descargarnos el paquete.

Para la versión 6.1:

wget http://nightly.openerp.com/6.1/nightly/deb/openerp_6.1-latest-1_all.deb

Para la versión 7.0:

wget http://nightly.openerp.com/7.0/nightly/deb/openerp_7.0-latest-1_all.deb

Después como root lo instalamos.

dpkg -i paquete.deb

Si nos falta alguna dependencia fallará. Lo más seguro es que nos sugiera un «apt-get -f install» para solucionarlo, si es así lo ejecutamos y seguimos. El problema es que el paquete deb no tiene como dependencia el servidor de Postgresql ya que este podría encontrarse en otra máquina. Nosotros lo vamos a instalar en la misma máquina que el servidor de OpenERP.

apt-get install postgresql-9.1

Nota: En mi caso el paquete se llama postgresql-9.1 pero esto puede variar ligeramente en vuestra distribución.

Tendremos que configurar postgresql para que autentique correctamente en local, además tendremos que crear un usuario para nuestra base de datos. Editamos el archivos /etc/postgresql/9.1/main/pg_hba.conf y cambiamos la linea:

local   all             all                                     peer

por

local   all             all                                     md5

En vuestro caso la linea puede ser ligeramente diferente. Después tendremos que reiniciar el servidor.

service postgresql restart

Añadimos el nuevo usuario a la base de datos. Primero nos autenticamos como usuario postgres (administrador de Postgresql por defecto).

su - postgres

Y luego creamos el usuario:

createuser --createdb --username postgres --no-createrole --pwprompt cheli

Le damos una contraseña, en mi caso cheli, y le indicamos que si sea super usuario.

Por último tenemos que editar el archivo /etc/openerp/openerp-server.conf y dejarlo así:

[options]
; This is the password that allows database operations:
admin_passwd = admin
db_host = False
db_port = False
db_user = cheli
db_password = cheli

Al reiniciar el servidor de OpenERP este ya podrá conectarse a la base de datos.

service openerp restart

Una vez haya arrancado el servidor tenemos que crear la base de datos, esta tarea la realizaremos desde el cliente web. Abrimos la siguiente url desde el navegador:

http://localhost:8069/web/webclient/home

Y pinchamos en el enlace «Manage Databases». En la nueva ventana pinchamos en «create» y rellenamos los campos:

admin (por defecto a admin, tal y como lo pusimos en el archivo de configuración)

cheli (le damos un nombre, en mi caso cheli)

English (US) (en mi caso English US)

Admin password: cheli (le damos una contraseña de administración)

cheli (repetimos la contraseña)

Si queremos que se cargue con datos de ejemplo entonces seleccionaremos la opción Load Demostration data.

Cuando se termine de crear la base de datos se autenticará automáticamente y ya estaremos en nuestro OpenERP completamente limpio. Las siguientes veces tendremos que autenticarnos con usuario y contraseña admin / cheli.

En el siguiente apunte os explicaré como cargar la localización para España, así que atentos.

Nota:

Estoy ofreciendo unos mini cursos de desarrollo en OpenERP gratuitos.

Cheli

Publicado el

Cómo compré mi billete a Madrid en Renfe

Mañana lunes voy a Madrid por trabajo, me lo notificaron hace unos 10 días y desde entonces me puse a mirar vuelos y trenes. Al final la mejor opción por horarios era el tren, pero tenía un problema, al coincidir con la vuelta de Semana Santa eran más caros y ya no quedaban apenas plazas.

Para el 9 sólo quedaban plazas en el primero de la mañana y en preferente, o eso pensaba yo ya que aparecía un radio button para poder seleccionar tanto la opción de preferente como la de turista pero al final sólo te dejaba seleccionar la de preferente. Yo no quería ir en preferente por ser 32,9€ más caro y porque en definitiva he viajado siempre en turista y se va bien en los Alvia. Así que pensé, ¿qué pasaría si modifico el html de la página para quitar la restricción en el radio button?, dicho y hecho.

 

Activé el Firebug y edité el código html para que me dejara seleccionar la opción de  turista. Una vez el código estaba listo volví a la página de compras, seleccioné la opción y seguí todos los pasos del proceso de compras, milagrosamente quedaban unas 4 o 5 plazas aún en turista y el proceso funcionó correctamente :D.

 

Pues nada, así es como conseguí mi billete en turista.

 

Cheli