Experiencias con Software Libre

Localización Argentina v2.0

2012-02-01T22:55:00.003-03:00

Localización Argentina v2.0

En esta entrada voy a detallar el resultado del trabajo realizando en los últimos 6 meses. Esta implementación funciona para la versión 6.0 de OpenERP. Debo aclarar que todavía no la probé con la versión 6.1.

Instalación Inicial

Las siguientes pantallas corresponden a la nueva forma de configurar la localización argentina.

La primera pantalla con la que nos encontramos cuando instalamos la localización argentina en una base de datos vacía es la configuración de la cuenta contable,

La siguiente pantalla que permite generar el Plan de Cuentas a partir de plantillas. Las plantillas disponibles son: Plantilla para Cooperativas, Plantilla para Responsable Inscripto y Plantilla para Monotributistas.

Si elegimos el plan contable argentino aparecerá la pantalla donde nos listará los módulos disponibles,

Si elegimos el módulo de facturación argentina aparecerá la siguiente pantalla de configuración,

en esta pantalla van a poder configurar los diarios necesarios para trabajar con facturas, notas de crédito y notas de débito según la responsabilidad con respecto al IVA. También si se quiere operar con dólares, si se quiere realizar operaciones de exportación, se permite eliminar los diarios de facturación existentes y el número de punto de venta con el que se va a trabajar. Esta pantalla puede ejecutarse todas las veces que sea necesario para poder crear diarios diferentes para cada punto de venta. Un tema que voy a dejar en la próxima versión menor es agregar la posibilidad de trabajar con talonarios multifunción.

Nuevos documentos

Este proceso de configuración e instalación de los módulos va a traducir los menúes de facturación a términos argentinos.

Habilitar el módulo de cartera de chequera agregará el siguiente menú,

El cual permitirá trabajar con valores,

y asociarlos con pagos,

Planes contables

Uno de mis esfuerzos esta concentrado en los diversos planes contables. No están revisados y esa es la razón principal por la que no quiero publicar estos desarrollos en el branch principal de la localización.

Facturación

La facturación electrónica no está implementada. Para su correcta implementación es necesario levantar todos los códigos del AFIP. Por ahora están cargadas las provincias. Hay que hacer un esfuerzo mayor para cargar el resto de las tablas. Ver Futuro.

Con respecto a la impresión de la factura, pueden encontrar el archivo invoice.rml que yo uso, donde pueden ver como se puede implementar fácilmente la impresión de facturas de cualquier tipo (A,B,C,E,M, etc..) para cualquier operación (Factura, Nota de Crédito, Nota de Débito). Me queda pendiente habilitar la factura como demo.

Impuestos

He revisado los impuestos y puedo decir que están funcionando bien. Definitivamente necesiten más testing, pero todo es fácil de resolver ahora.

Está implementado el IVA del 10.5%, 21% y 27%. También está implementado los Ingresos Brutos de Capital Federal, Buenos Aires, Córdoba y Santa Fé; tanto como retenciones como percepciones.

El reporte de declaración jurada debería funcionar correctamente, generando la suma correcta a pagar de los impuestos. Digo debería porque para mi funcionó, pero nuevamente, esto necesita más testing.

Cartera de Cheques

El módulo que lo implementa es clásico y conocido treasury, aunque lo he adaptado a la versión 6.0 para que pueda funcionar con los recibos (vouchers). Además programé un simple workflow para determinar si se ha cobrado o no el cheque y su estado. También permite seguir el cheque desde su recepción hasta su emisión. Esta realmente interesante, aunque falta trabajar con la parte contable. Eso significa asentar las operaciones de cobro una vez que se cobro el dinero ya sea por depósito o por retiro en ventanilla. También hay que programar el caso en que el cheque es rechazado, donde se debería generar una nota de débito al partner con el valor del cheque, los gastos administrativos tanto del banco como del cobrador, y potencialmente el interés que provoque el atraso del pago.

Algo que hay que trabajar también es con otras formas de pago como son las tarjetas de crédito y débito, y transferencias bancarias, que la cartera de cheques también funciona.

Otros detalles

Agregué más títulos de partners relacionados con Cooperativas y títulos de profesionales.

Sigue funcionando el sistema de reconocimiento de CUIT.

Sigue la lista de los bancos argentina. No tuve tiempo de verificar si este año existieron modificaciones.

Cómo trabajar con la localización 2.0

Estoy preparando un video explicando como trabajar con esta configuración. Necesito un par de días para ello.

Descargar el desarrollo

Para descargar esta versión hay que acceder a la mi repositorio de Launchpad

$bzr branch lp:~cristian-rocha/openerp-argentina/6.0

Futuro

En el futuro deberíamos concentrarnos en principio seguir la lista de tareas de pendientes de la localización, o en otras palabras los blueprint. Todavía seguimos muy desorganizados. A pesar de ello voy a enumerar que tareas quedan pendientes en mi implementación:

Revisar y confirmar las cuentas contables.
Permitir a los remitos ser pagados con múltiples formas de pago.
Cargar las tablas del AFIP para poder implementar la facturación electrónica on-line.
Habilitar la impresión de factura demo.
Programar asientos contables por cheques aceptados.
Programar generación de nota de débito por cheques rechazados.
Implementación de pagos con tarjetas de crédito y débito.

Eso es todo por ahora. Nos vemos pronto.

OERPenv, en busqueda de nuevas funcionalidades

2012-01-30T12:56:00.004-03:00

Hoy quisiera comentar las funcionalidades en las que estoy trabajando para OERPenv. Para quienes no conozcan este desarrollo, este permite administrar ambientes de desarrollo para OpenERP de una forma sencilla.

Propuesta

En esta entrada tengo como objetivo hablar de una nueva funcionalidad que permitirá trabajar más cómodamente con bugs y nuevas funcionalidades en un ambiente de producción usando dos nuevos comandos: deploy y fallback.

En el diagrama muestro los actores a quienes está enfocado el OERPenv y los usos ya implementados (naranja) y los que estoy describiendo en esta entrada (verde)

El ambiente de desarrollo y el de producción se diferencian principalmente por la estabilidad del software. En producción no debería ocurrir ningún error, y si ocurre hay que trasladar (fallback) el código en producción a un ambiente de desarrollo que donde las modificaciones afecten al usuario hasta que se hayan arreglado. Una vez arreglado hay que actualizar (deploy) el servidor en producción con un impacto mínimo el trabajo diario del usuario. Algo muy parecido ocurre en el caso de una nueva funcionalidad.

Estos nuevos comandos tendrán un uso exhaustivo de sistemas de control de versiones.

El sistema de control de versiones, el cual mantiene diferentes versiones del software que desarrollamos, nos permite recuperar la versión que mejor funciona y desarrollar sobre otra. OERPenv actualmente soporta Subversion y Bazaar. Subversion nos permite trabajar con módulos exclusivo para nuestros clientes, evitando tener que publicar desarrollos sensibles al negocio. Bazaar, en cambio, nos permite acceder a launchpad, el ambiente principal de desarrollo de OpenERP y sus módulos.

No quiero entrar en detalle de cómo usar un sistema de control de versiones, pero si puedo recomendar ver el siguiente URL: http://blog.tfanshteyn.com/2009/08/source-control-management-201.html

Otro punto importante es que el comando fallback debe copiar la base de datos del ambiente de producción al ambiente de desarrollo.

Todo está listo para implementarse. Pero todavía estoy en proceso de discusión sobre la funcionalidad. Estoy abierto a cualquier opinión y observación.

Futuro

Una funcionalidad que me gustaría agregar, y que va en dirección de esto pero que veo difícil de llevar a cabo es lograr "tomas/snapshots" de el estado del servidor de producción en un momento previo a que ocurra un bug. Por lo tanto se podría realizar un fallback del estado previo a la ocurrencia del bug, junto al conjunto de eventos que ocurrieron luego que provocaron el error.

El problema de esto es poder conseguir el estado de la base de datos en ese momento. Para ello hay que combinar un log de commits con el log de openerp cuyo nivel de detalle debería ser lo suficientemente sensible para generar un script de testing.

Si les interesa más sobre el futuro de OERPenv y la tecnología que debería usar pueden ver los siguientes links:

http://www.mkyong.com/database/postgresql-point-in-time-recovery-incremental-backup/

http://doc.openerp.com/v6.0/technical_guide/audittrail.html

Administrar ambientes OpenERP

2011-10-31T01:06:00.001-03:00

Quizás una de las fallas más importantes que le he encontrado al desarrollo en OpenERP es la falta de herramientas de mantenimiento y desarrollo.

Por ejemplo no es fácil migrar un módulo de una versión a otra de OpenERP. Tampoco es fácil encontrar errores en un ambiente retocado, y donde la única solución es empezar de cero con la base de datos y no hablar cuando se toca un poco del código original de OpenERP. Y no hablemos de estudiar el impacto que tiene un update del código de OpenERP en una base de datos conocida.

Todo esto son simples tareas que trato de minimizar con mi último desarrollo OERPEnv, o en otras palabras OpenERP Environment Administrator.

Esta herramienta puede crear un ambiente independiente del python, módulos y versiones instaladas en el sistema operativo. También puede descargar y actualizar los fuentes de openerp en las versiones 5.0 y 6.0 (hasta ahora), ejecutar test de unidad y ejecutar los clientes de acuerdo al testing funcional que se quiera ejecutar a mano.

Como el desarrollo está en sus primeros pasos no recomiendo utilizarlo en un ambiente de producción. Pero está listo para empezar a usarse en un ambiente de desarrollo.

Pueden encontrar el código fuente en bazaar donde encontrarán más documentación.

Les doy un conjunto de comandos que pueden ejecutar una vez instalado el oerpenv. Con ellos pueden lograr tener un nuevo módulo funcional, listo a desarrollar en pocos pasos:

Primero creo un ambiente que voy a llamar foo

$ oerpenv init foo

Terminado el comando se tendrá un directorio foo en donde estará el código fuente del openerp v6.0 y todos sus addons dentro del directorio foo/sources.

Luego entro al directorio foo e instalo en el ambiente python las aplicaciones cliente y servidor.

$ cd foo

$ oerpenv install

Terminada la instalación ya podemos crear un paquete vacío que llamaremos mymodule.

$ oerpenv dummy mymodule

El módulo creado es operativo, aunque no hace nada. Pero podemos probar que el servidor openerp puede cargarlo y ejecutar sus test. Pero antes debemos habilitar el módulo.

$ oerpenv enable mymodule

Ahora si, podemos ejecutar el servidor en modo de testing de unidad para el módulo mymodule.

$ oerpenv test mymodule

Este comando crea una base de datos vacía con el nombre test_mymodule donde el servidor creará una instancia openerp. Hay que asegurarse que el postgresql esté corriendo con los permisos correspondientes.

En una nueva terminal podemos ejecutar el cliente openerp donde vamos a ver el cliente funcionando:

$ oerpenv client

Con esto tenemos una vista rápida de las capacidades del administrador de ambientes de openerp.

Instalando el clock_reader

2011-08-09T10:44:00.000-03:00

En la siguiente entrada voy a explicar rápidamente como descargar y hacer funcionar el sistema de reloj para OpenERP v5. La v6 todavía no fue testeada. En resumidos pasos hay que realizar:

Descargar e instalar Bazaar
(ver http://wiki.bazaar.canonical.com/Download)
Descargar e instalar Mercurial
(ver http://mercurial.selenic.com/wiki/Download)
Descargar e instalar el OpenERP
(ver http://doc.openerp.com/v6.0/install/index.html)
Descargar módulo Zkemapi
(ver hg clone https://bitbucket.org/johnmc/zkemapi)
Instalar el módulo Zkemapi
(cd zkemapi; sudo python setup.py install - Solo en Cygwin y Linux)
Descargar e instalar el branch de openerp-argentina de mi persona
(bzr branch lp:~cristian-rocha/openerp-argentina/5.0)
Copiar o Linkear el contenido de clock_reader al directorio addons de OpenErp
(ln -s clock_reader $OPENERPROOT/addons - Solo en Linux)
Actualizar lista de módulos de OpenErp
Instalar el módulo clock_reader

Con estos escuetos pasos se puede instalar el módulo. Ahora hay que configurarlo.

Identificar el IP del lector de asistencias.
Crear una entrada de reloj en la configuración de recursos humanos.
Configurar el reloj:

Aquí se tienen varias opciones.

El IP del lector se asigna en el campo URI. Si el reloj está en el IP 192.168.1.43 y el puerto de conexión es 4370 entonces el campo deberá contener: udp://192.168.1.43:4370

Tilde el campo Active y elija "Zkem" para el campo Model que es el único modelo ahora soportado.

En principio el clock_reader identifica a un personal a través del Other-ID del objeto Employee. Si este no hay empleado con un ID leido desde el reloj se pueden hacer dos cosas: a) ignorar al empleado o 2) crear un empleado nuevo. Eso lo pueden configurar en la opción "Create Unknown Employeers"

No siempre los empleados se registran correctamente, y el sistema OpenERP exige que no puede existir una registración de salida si no existió una registración de entrada previamente. Si se quiere ignorar el cómo se registró el empleado puede confirmarlo en la opción "Ignore sign in/out".

En el caso que no quieran perder la información administrada por el empleado (una entrada o salida) el sistema puede agregar automáticamente registraciones en el medio de manera tal de mantener la restricción sin problemas. Eso se puede configurar con la opción "Autocomplete sign in/out".

A mi no me funcionaron ninguna de las dos opciones anteriores. Pero mejor me funcionó eliminar la restricción de OpenERP. Por lastima hay que tocar el archivo attendance.py para ello (es fácil de encontrarla). Si realizan esto podrán activar la opción "Ignore DB restriction" para que no intente chequear que no se cumplen las restricciones.

Si quiere eliminar todos los registros una ves leído el sistema pueden configurar la opción "Clean Clock at the end".

Otras opciones importantes a configurar son:

Timeout: cantidad de segundos hay que esperar al reloj para que de su respuesta. Un buen valor son 10 seg. Esto va a depender de la calidad de la red.

Tolerance: si existen dos registraciones en el tiempo definido se toma como una sola. Un buen valor son 300 seg, o sea 5 minutos.

Location: lugar físico donde se encuentra el reloj.

Para probar el reloj puede apretar el boton de acción "Read clock". Aquí ya va a cargar todos los registros de asistencias (attendances) a la base de datos, por lo que recomiendo no hacerlo en el servidor de producción la primera prueba.

El resultado de la lectura será una pantalla con los errores ocurridos.

Recomendación. Una vez en producción es bueno leer el reloj en un lapso de tiempo predeterminado, eso puede hacerlo creando la siguiente entrada en el Planificador (Scheduler).

Crear una nueva entrada por cada reloj conectado con los siguientes valores:

Nombre: Lectura del Reloj
Usuario: Administrador
Activo: Si
Prioridad: 5
Número de intervalo: 1
Unidad de intervalo: horas.
Próxima fecha de ejecución: Elegir alguna válida.
Número de ejecuciones: -1 (Infinitas veces)
Repetir perdidos: No

Por ejemplo:

Eso es todo.

Saludos!

Modulo de CUIT para OpenERP 6.0

2011-06-04T22:02:00.001-03:00

Hoy tengo dos novedades.

Primero, he movido mi desarrollo de la versión 5.0 en un nuevo branch que llame 5.0. Y ahora el trunk corresponde a la versión 6.0.

Y con respecto a la segunda novedad, he implementado un nuevo módulo para soporte de CUIT argentino independiente del modulo original de openerp. Este nuevo se llama base_vat_ar. Que ventajas tiene eso? Si se actualiza el módulo base_vat en el trunk de openerp esta no afecta al sistema.

Para usar este módulo en la versión 6 solo hay que instalar el módulo como cualquier otro y usar como prefijo ar para indicar el originen del VAT, en nuestro caso CUIT. Ej: ar232X09X45X9

Mis próximas actualizaciones se centrarán en clock_reader y hr_attendance_analysis, por lo que no se atrevan a usarlas.

Mis módulos en la v5 están ahora en: lp:~cristian-rocha/openerp-argentina/5.0
y los módulos de la v6 están en: lp:~cristian-rocha/openerp-argentina/trunk

Advertencia: Si alguien está usando mis módulos, por favor tengan en cuenta de realizar actualizar las url de sus repositorios si no quieren perder los módulos, ya que estoy borrando algunos que encuentro obsoletos.

Eso es todo por hoy.

Samsung RF511 S01 y Debian

2011-05-26T10:38:00.000-03:00

Ayer en un ataque de locura y desesperación fui a Falabella y me conseguí una nueva notebook. Fui en contra de varios de mis principios.

Hay que comprar por Internet. En el negocio no solo perdes el tiempo en el viaje sino también discutiendo con el vendedor.
El modelo tiene que ser de menos de 15''. Tiene que ser practica y no un mastodonte.
No DEBE tener lectora óptica de ningún tipo. No tiene sentido su existencia.
Pero claro, también queria algo poderoso para desarrollar y que sea lo mas compatible con linux.

Y terminé comprando en el negocio con 10% de descuento en Falabella, solo porque en las páginas web de las empresas no tienen ninguna opción (me fije en DELL, HP, Lenovo... nada!) De 15.6" y con un cacho de lectora grabadora Bluray compatible.

Resultado: una increíblemente poderosa y apestosa máquina.

Vayamos por parte.

Esta maquina tiene uno de los mejores procesador i5 del mercado argentino. El i7 todavía sigue siendo raro en estas latitudes y muy caro.

Lo que a mi mas me interesa es la placa gráfica. Y ahí me agarre un gran chasco! Definitivamente las placas nvidia siguen siendo las más poderosas y fácil de configurar en linux. Y esta maquina viene con una Gforge GT540M, una muy poderosa para notebooks. Pero... tambien trae una Intel! Si, tiene dos placas de video...

Bue, el resumen es que esta nueva tecnología Optimus de Nvidia no esta oficialmente soportada para Linux. Entonces nació Bumblebee - Cortito, quien no sabe de los Tranformers, Optimus Prime es el héroe superpoderoso y Bumble Bee es el robotito mejor amigo de los humanos. La idea de esta tecnología es no comerse la batería con los 96 núcleos de la placa Nvidia, entonces la Nvidia solo se prende cuando hacemos lindos gráficos 3D.

Bumblebee es un soporte de Optimus basado en la creación de dos instancias del X (El sistema core de la gráfica de Linux) uno donde corre la interface Intel oficial y otra donde corre la Gforge. El único problema que tiene es que no identifica automaticamente una aplicación 3D, sino que hay que indicarle con un comando al ejecutarla. Pero eso es lo de menos, porque la Intel también tiene su capacidad 3D. Es divertido ver a la Intel trabajando con Compiz y a la Gforge con biomoléculas de >32000 átomos.

Bue, si quiren saber más de cómo configurar a Bumblebee debén ir a la página oficial. Pero antes le dejo dos tips:

1) Descarga: git clone https://github.com/MrMEEE/bumblebee.git
2) Usar la versión inestable de Debian.

Eso es todo por hoy.

Incompatibilidad de Squid y CherryPy

2011-05-18T18:20:00.000-03:00

Esto va a ser rápido.

El Squid y el CherryPy no se llevan bien. La razón es porque CherryPy espera conocer la URL original a través de la cabecera de http "X-Forwarded-Host". Y claro, los únicos proxies reversos que añaden esa cabecera son Apache (mod_proxy) y Lighttp. Pero no ocurre eso con Squid. No es que Squid no publique esa información, sino que lo publica en la variable "Origin". El resultado es que pueden funcionar los dos sistemas al mismo tiempo excepto que modifiques parte del código el CherryPy.

En archivo lib/cptools.py, ubicado dentro de la raiz del CherryPy (v3) pueden encontrar la función proxy. Con solo modificar la variable de entrada de la función "local" que está seteada por defecto en "X-Forwarded-Host" a "Origin" es suficiente. Y se van a ahorrar un largo y sensible dolor de cabeza que me llevó unas 4hs resolver.

Eso es todo, excepto que se pregunten a quien le sirve esta cháchara. Bue, en principio a quien quiera instalar el cliente Web del OpenERP detrás de un proxy reverso del tipo Squid.

Mi celular con Android

2011-05-14T10:43:00.001-03:00

Luego de un tiempo largo buscando un celular con Sistema Operativo Linux he encontrado algo que me convence y mucho. Es verdad que la mayoria de los sistemas para celulares tiene alguna version de Unix, pero eso para mi no es sufiente. Es una necesidad absoluta tener la posibilidad de acceder al SDK en forma gratuita, y no hablar del código fuente libre. Y Android cumple con todas estas pautas. Falta confirmar las licencias, pero por ahora no me parece relevante.

Sinteticamente, con una pobre experiencia de uso puedo decir que:

Ventajas:
1. Cantidad increible de aplicaciónes.
2. Integración al extremo con google.
3. SDK accesible.

Desventaja:
1. En mi modelo Motorola Slice se cuelga. La razón probable es que su memoria y procesador no son suficiente. Dicen que los modelos de Samsung son mucho mejores.
2. Usa mucho Internet para integrarse a google. Por suerte existe una aplicación que previene a las aplicaciones acceder a internet: apndroid.
3. La máquina virtual SDK es increiblemente lenta en Linux, al menos.

La conclusión es que al fin alguien entendió que un celular es parte de Internet. Sinceramente me sorprendió la integración, mucho mejor que iphone u otros. Quien quiera desarrollar para esta plataforma tiene que tener una perspectiva diferente.

Análisis de Asistencias, primera aproximación a la Liquidación de Sueldos

2011-03-22T00:07:00.000-03:00

Luego de tres meses de intenso trabajo puedo decir que tengo listo mi próximo módulo: hr_attendance_analysis.

Éste módulo permite realizar cálculos sobre las horas trabajadas por parte de los empleados. Acepta diversas fórmulas y cálculo de reglas para automatizar todo lo que más se pueda. Tanto que está pensado para trabajar (aunque no es necesario) con el módulo clock_reader.

A pesar de ello el módulo tiene un workflow para ir confirmando la calidad de los datos de cada tipo de documentos: journal y payroll. El primer documento es la información diaria del empleado, mientras que payroll es el resumen del mes, quincena o jornada.

Estos son los primeros screenshots del sistema.

En esta imagen pueden ver el menú principal del manejo de recursos humanos. Ahí pueden ver las opciones para acceder a los documentos Payroll (el seleccionado) y Attendance Journals.

Aquí pueden ver el documento con las horas resumidas de los empleados en un rango dado. Pueden dejarse notas por cada empleado y al documento completo. También se puede ver que tiene dos estado básicos: draft y validado. Todavía falta desarrollar el workflow, para permitir cancelar y reiniciar el documento.

En esta otra pantalla vemos la entrada del Journal del empleado. Aquí se ven en detalle las horas en que entró y salió en una fecha dada. También las licencias (Vacaciones, Licencias, Llegadas tarde, Salidas tempranas, Enfermedad, etc..). A la izquierda puede verse el resultado del cálculo de horas.

Esta es una fórmula de sumarización de los valores almacenados en el Journal, para ser mostrado por el documento Payroll.

En cambio esta es una fórmula para calcular las horas normales en un día determinado para un empleado determinado.

En esta captura, a diferencia de las dos anteriores, no se trata de una fórmula sino de una regla. Es una regla que asigna razones de acciones a las entradas y salidas de asistencias. En este caso podemos ver como calcular una salida temprano sin aviso.

Por ahora cuento esto. Todavía falta cerrar algunos puntos, pero me gustaría conocer opiniones y cambios que consideren importante a la hora de realizar Liquidación de Sueldos.

Reportes apaisados con OpenERP

2011-01-12T11:06:00.007-03:00

Esta entrada tiene como objetivo explicar cómo apaisar un reporte ya generado con OpenERP y ReportLab. Si no sabes de que estoy hablando puedes, como mucho leer, los tres primeros parrafos, si ya sabes de que se trata pasa directamente al cuarto parrafo.

OpenERP utiliza en su nucleo a ReportLab como generador de reportes. ReportLab es un software capaz de generar archivos PDF a partir de funciones de python. Y una de esas funciones permite generar un reporte a partir una plantilla en XML, o en forma más específica RML.

El lenguaje RML es en esencia muy parecido a XHTML. Tiene tags como TD, TR, PARA para describir la organización del documento, y tiene además otros tags ya más específicos de la impresión de la hoja. Si quiere aprender más de éste lenguaje recomiendo ller el User Guide de RML.

El tag que nos incumbe es el

<template allowsplitting="True" author="Cristian S. Rocha" pagesize="(595.0, 842.0)" title="Daily Report">

que indica el tamaño de la página (pageSize), el título del reporte (title), el autor (author) y el reporte se va a dividir en varias páginas.

Para lograr reportes apaisados hay que intercambiar el alto por el largo de la página, quedando la linea anterior cómo:

<template allowsplitting="True" author="Cristian S. Rocha" pagesize="(842.0, 595.0)" title="Daily Report">

Pero con esto no es suficiente, debemos modificar el método de rendering de la página. Para ello la gente de OpenERP ha desarrollado el módulo "rml_parse.py" que justamente modifica la forma de leer el archivo para permitir la impresión apaisada.

Imaginemos que ya tenemos un reporte y lo queremos apaisar. Éste debería encontrarse en un directorio llamado report dentro de ótro directorio correspondiente a la extención de OpenERP que estamos modificando. Por supuesto, todo dentro del directorio addons. El primer paso seria copiar el archivo "rml_parse.py" al directorio report. Este archivo puede encontrarse en otros directorios reports de alguna extensión (locate rml_parse.py es una instrucción en BASH que va ayudar a localizarlo).

Una vez copiado el archivo hay que modificar el método de rendering en el módulo de python asociado al reporte. Por ejemplo, si tienes un archivo test.rml en el directorio report deberías tener otro archivo test.py con la siguiente linea en su interior:

report_sxw.report_sxw('report.my_addon.test', 'hr.employee',

'addons/my_addon/report/test.rml',parser=test_class, header=2)

Ese archivo debería tambien contener la siguiente linea

class test_class(report_sxw.rml_parse):

que la debemos cambiar por

class test_class(rml_parse.rml_parse):

y agregar al comienzo del archivo la linea:

import rml_parse

y con eso ya podemos disfrutar del informe apaisado. Por supuesto, hay que acomodar las tablas y texto para que quede acorde a las nuevas coordenadas.

Nuevo módulo para conectar relojes de control de personal con OpenERP

2011-01-05T11:50:00.002-03:00

Aquí vamos de nuevo, pero esta vez con algo original desarrollado por mis socios y yo. Luego de un par de semanas tenemos el agrado de comunicarles que ya tenemos la versión Beta del módulo "clock_reader". Éste permite conectarse con el reloj F5 distribuido por Dígito-Uno en Buenos Aires, y aparentemente con el modelo de reloj G3T de Asensio Sistemas que se puede encontrar en Rosario.

El módulo está preparado para leer más de un reloj, que pueden estar conectados en diferentes lugares de la empresa o incluso tener varios en una entrada en el caso que se quiera tener un backup o simplemente se quiera contabilizar el acceso de muchos empleados en un lapso más corto.

Aquí les presento algunas pantallas, empezando la solapa del módulo.

El módulo crea un nuevo objeto "clock" que puede listarse desde la opción "Clock" del menú "Recursos Humanos" opción "Configuración".

Éste objeto tiene como atributos el nombre del reloj, la URI al reloj (ver más adelante), el modelo o driver a utilizar, una localización y si está activo o no.

Y para realizar la lectura hay que acceder al menú "Recursos Humanos" y presionar la copión "Clock read" dentro de la opción "Asistencias".

La ejecución solo presenta una ventana donde se confirma que se quiere leer el reloj. Y una vez leído, presenta una ventana con la cantidad de asistencias leídas y los errores que se cometieron.

He preparado todo para aceptar más de un modelo de reloj, pero como solo tengo acceso a un modelo F5 solo pude programar ese módulo. Si quieren agregar un nuevo modelo hay que desarrollar una clase python que tenga la siguiente interface:

def __init__(self, uri): Permite iniciar la clase del reloj. El URI es un string que describe el puerto donde uno se conecta. Por ejemplo, como el reloj permite conección por UDP el URI que usamos es: udp://192.168.1.20:9999
def test(self): Chequea que se puede conectar al reloj. Devuelve False si no es posible. En la clase para el reloj F5 es conveniente indicar un timeout, porque si el reloj no está conectado puede que entre en un loop infinito. Yo estoy usando un timeout de 3 seg. Y todo esto por usar un protocolo como el UDP.
def connect(self): Prepara la clase para que pueda realizar las próximas operaciones. Puede también devolver información del dispositivo. Por ejemplo, en mi clase devuelve la versión del Firmware.
def attendance(self): Es una función de iteración que devuelve en cada iteración cada asistencia con información del identificador del reloj, la hora y si es entrada o salida. También puede devolver el método de entrada que realizó: por el teclado, con tarjeta o con huellas digitales.
def clean(self): Borra los registros almacenados en el reloj.
def disconnect(self): Se desconecta del reloj.

Con una clase que cumpla con esta interface, el sistema de lectura ejecuta cada reloj activo y agrega las asistencias al módulo hr_attendance de OpenERP.

Con respecto a agregar asistencias, el OpenERP tiene en cuenta que no se pueda ingresar sin antes haber salido, y al revés. Pero muchas veces los relojes no pueden controlar la situación, los empleados tienen muchas escusas para no registrarse en el reloj (el trabajo manual les elimina las huellas digitales, por ejemplo) por lo tanto es difícil complacer las restricciones del OpenERP. Una solución que estoy estudiando poder crear automáticamente las salidas y las entradas según el turno que debe cumplir el empleado para luego ser modificadas manualmente.

Con respecto a la ingeniería inversa necesaria para desarrollar más controladores de reloj, pueden buscar en el directorio test dos interesantes archivos de python.

El primero, research.py, tiene una función para leer capturas realizadas con Wireshark o cualquier otro que exporte las capturas en XML PDML (readpackets). También tiene funciones para chequear que la conexión no es encriptada (plothistogram) como también para buscar patrones (dotplot y align)

El segundo, server_f5.py, es un reloj virtual que toma una captura (deje tres en el directorio data) y se queda escuchando para que el cliente que ustedes programen se conecte y le realice las consultas.

Si alguno de ustedes necesita ayuda para desarrollar un nuevo módulo, no duden en pedir ayuda. Incluso si el reloj se conecta por RS232 o USB.

Me olvidaba, el módulo lo pueden obtener en Launchpad:

https://code.launchpad.net/~cristian-rocha/openerp-argentina/trunk/

Módulos no oficiales de OpenERP para Windows, ó simplemente Bazar en Windows

2011-01-05T10:58:00.000-03:00

OpenERP tiene varios módulos no oficiales. La mayoría de ellos se encuentran en un sistema de repositorios conocido como Launchpad, un repositorio de código fuente pensado para aplicaciones opensource. Ahí podemos encontrar OpenERP en su forma más pura en su última versión. Pero no voy hablar de OpenERP en este post, sino de otros módulos, como son los de OpenERP Argentina.

Launchpad funciona con un sistema de control de versiones (CVS) distribuido conocido como Bazaar. Este sistema es un tanto complicado de usar, especialmente para un desarrollador, pero para un usuario con seguir los pasos básicos es suficiente.

Bazaar y Lauchpad ya tiene suficiente soporte en Unix (Linux en particular), por lo tanto decidí realizar el post para Windows y por suerte tengo VirtualBox.

Primero tienen que descargar el Bazaar para Windows aquí. Si no saben manejarse con Python les recomiendo que descarguen el paquete completo de la versión estable 2.2. Una vez descargado ejecuten e instalen.

Una vez instalado ya podrán ejecutar el "Bazaar Explorer", que le abre una primera pantalla tal como se ve en la siguiente imagen.

Lo que vamos a hacer en este caso es descargar el OpenERP-Argentina. Éste se encuentra en el repositorio OpenERP lp:openerp-argentina, y lo vamos a descargar dentro del directorio Sources. Esto se hace desde a opción "Obtener fuente del proyecto.." de la imagen anterior, en donde se abrirán otras dos opciones: "Rama" u "Obtener". Lo que queremos hacer, ya que estamos interesados en usar el módulo y no en desarrollar, elegimos la opción "Obtener". Ahí indicamos el repositorio y el destino del fuente como se ve en la próxima imagen.

Aceptamos y empieza la descarga del código fuente. Gracias a que el código está en Python no va a ser necesario compilar por lo que una vez terminada la descarga solo tenemos que copiar el módulo al directorio addons del OpenERP.

Con esto tienen suficiente para divertirse.

Diseño de Facturas en OpenERP

2010-12-24T20:46:00.001-03:00

Acabo de darme cuenta que uno de los problemas más complicados de resolver sin ayuda en OpenERP es el diseño de Facturas.

Las facturas en OpenERP son reportes, eso significa que si modificamos el diseño de una factura, los reportes sufrirán su suerte. Que quiero decir con esto? Que si utiliza facturas pre-impresas, los reportes deberán perder toda su gracia, llámese cabeza y pie de página. Lo que no se si es válido es pedir a la imprenta que no sean ellos quienes impriman la cabeza y el pie de página, sino apenas el número y letra de la factura, y como mucho el encuadre.

Pero supongamos que queremos quedarnos con las facturas ya impresas. Entonces hay que eliminar lo dicho previamente. Eso se logra en el árbol de Administración, opción Usuarios/Estructura de la Compañía/Compañías.

Ahí habrá que seleccionar nuestra compañía y modificar en la pestañas Cabecera / Pie de página la entrada en XML al siguiente XML:

<header>
</header>

Para la primera página ya hemos limpiado la cabeza y pie de página. Si se quiere lo mismo para el resto de las páginas habrá que modificar el XML en la pestaña Cabera / Pie de página interna.

Esto eliminará en todos los informes el texto de cabeza y pie de página. Lo que no eliminará es el logo. Tendremos que ir a la pestaña Información General y eliminar la imagen presionando sobre el icono de la escoba.

Ahora el tema se complica. Eliminado el texto molesto, hay que generar el informe. El diseño del mismo está en el código XML que describe el reporte, y éste se encuentra en el sistema de archivos del servidor OpenERP.

Una vez dentro del servidor hay que acceder a ese archivo que se llama invoice.rml. Y se encuentra en el directorio addons/account/report a partir del raíz del servidor. En mi sistema Debian lo encuentro en forma absoluta en /usr/share/pyshared/openerp-server/addons/account/report.

Este archivo ya tiene información, en general mucha, y sobra si tenemos la factura preimpresa. Una buena práctica es copiar el archivo en el mismo directorio a algún nombre tipo invoice.rml.ori para no perder el archivo que sabemos que funciona. Y luego editar en el.

El formato de estos archivos es RML, o sea, un XML diseñado para Reportes por el grupo de desarrolladores de ReportLab. Para leer más detalles de éste formato pueden encontrarlo en este documento.

Este archivo contiene tres marcadores importantes: template, stylesheet e story. Y de las tres, la que nos interesa son template y story. En template describiremos como se distribuye el texto en la página y en story definiremos el texto en si.

Por ejemplo podemos definir secciones para la fecha, el cliente y su dirección de la siguiente manera:

<pageTemplate id="first">
<frame id="date" x1="13.5cm" y1="21.5cm" width="5.5cm" height="1.2cm"/>
<frame id="partner" x1="3.5cm" y1="18.9cm" width="15.5cm" height="1.2cm"/>
<frame id="address" x1="4.0cm" y1="18.0cm" width="15.0cm" height="1.2cm"/>
</pageTemplate>

y la forma de asignarle un texto a cada sección es:

<story>
<para style='body'>31/12/2010</para>
<nextFrame/>
<condPageBreak height="12"/><para style='body'>Cristian Sebastian Rocha</para>
<nextFrame/>
<condPageBreak height="12"/><para style='body'>Av. Rivadavia 555</para>
</story>

Por supuesto que si escribimos ese texto, siempre imprimiremos el mismo cliente con la misma dirección. Aquí hay que poner texto python de la siguente manera:

<story>
<para style='body'>[[ formatLang(o.date_invoice,date=True) ]]</para>
<nextFrame/>
<condPageBreak height="12"/><para style='body'>[[ o.partner_id.title or '' ]] [[ o.partner_id.name ]]</para>
<nextFrame/>
<condPageBreak height="12"/><para style='body'>[[ o.address_invoice_id.street ]]</para>
</story>

Con esto ya es suficiente para empezar a imprimir en todas las facturas preimpresas.

Facturación en Argentina con OpenERP, primera aproximación

2010-12-18T10:58:00.002-03:00

Luego de un tiempo largo estudiando cómo permitir la facturación en OpenERP he logrado llegar a algunas conclusiones. Aquí voy a describir primero que casos existen en argentina y como se podría llegar a encarar cada uno de ellos.

Modos de facturación.

En Argentina se trabaja con cinco tipo de facturas diferentes: A, B, C, M y E. Éstas están grabadas de diferente manera con el IVA y su emisión depende del emisor y receptor de la misma. Incluso podría haber otro impuesto que desconozco.

Aquí hay varios puntos importantes para quien quiera facturar:

Informes de IVA ventas y compras: El usuario debe poder identificar cuanto tiene que pagar al AFIP según lo que se vendió y compró. Eso sale de éste informe. Para generar este informe hay que identificar los impuestos gravados en cada operación. El OpenERP permite asignar los impuestos desde la emisión de la factura o desde la definición del producto. La solución a este punto es crear el Diario de IVA ventas y compras. Éste está incluido en la localización argentina.
Impresión de Facturas: Aquí hay cuatro casos disjuntos en la Argentina:

Se imprime los detalles sobre una factura preimpresa, y NO hay interés de asociar el # de factura al # de asiento: Este caso es el más sencillo ya que casi no hay que modificar la configuración inicial de OpenERP. Simplemente se utiliza un único diario donde se asientan los movimientos.
Se imprime los detalles sobre una factura preimpresa, y SI hay interés de asociar el # de factura al # de asiento: Para este caso hay que asociar un diario por cada tipo de factura y al configurar por primera vez hay que indicar cual es el número de factura se va a imprimir en el próximo movimiento. Esto es fácil, el OpenERP tiene la posibilidad de armar tantos Diarios como sean necesarios, y también asociar a cada diario con una secuencia diferente. Por lo tanto solo hay que generar tantos diarios de comprar y venta como sean necesarios para cada tipo de factura, e igual manera con las secuencias.
Se imprime la factura completa, no hay preimpresión. En éste caso se usa una impresora homologada por la AFIP ya que hay que garantizar que no se puede saltear o duplicar el número de factura. En el caso que se quiera hacer hay que configurar el OpenERP tal como se explica en el caso anterior y mandar a imprimir con el número de factura generada por OpenERP.
Se realiza factura electrónica. Este sistema permite imprimir la factura y asentar el documento fiscal en el servidor de la AFIP. Es realmente cómodo ya que uno está declarando de forma automática las operaciones realizadas. Para ello hay que estar constantemente conectado a Internet, donde la comunicación al servidor es a través de WebServices, dando la opción de trabajar con diversas tecnologías. Si todavía hay preguntas sobre esto, como son : Qué es? Cómo se implementa? Cuándo tiene lógica usarla? Quién puede usarla? pueden buscar más información aquí. Cabe aclarar que existe un módulo publicado en la localización de OpenERP para Argentina. Todavía no lo implementé, pero leyendo la documentación para desarrolladores de facturación electrónica, se puede llegar a adaptar fácilmente a los requerimientos del cliente.

Devoluciones, tanto por parte del cliente como por parte del proveedor. El usuario debería poder asentar estos movimientos, y el OpenERP lo permite. No me queda claro si está implementado tal como se tiende a usar en la Argentina, especialmente con varios tipos de facturas. Si la devolución es de una facturación de tipo A, debería asentarse en el diario asociado a la factura de tipo A? O es otro diario complemente diferente?

Secuencias, Diarios y Asientos

El manejo de finanzas en OpenERP se manejan a través de estas tres entidades. Las secuencias manejan la numeración de los asientos en los diarios. El diario es donde se colectan los asientos, y los asientos son cada movimiento fiscal: emisión de facturas, devoluciones, pagos, etc.

Se pueden crear tantas secuencias como se quiera, es una entidad base de OpenERP y también puede asociarse a movimientos de stock u otra entidad que necesite enumerar las "operaciones".

Existen dos tipos de Diarios, el primero asociado a asientos legales (Diario financiero) y el otro a asientos internos (Diarios Analíticos). El OpenERP permite cruzar estos diarios y así poder tener diferentes vistas de un movimiento fiscal. Por ejemplo un movimiento de facturación se va a asentar en el "Diario Ventas" en la cuenta "Ingreso por Ventas" y se podría asentar también en el "Diario Vendedores" como una cuenta de "Ventas realizadas por Cristian", como también en el "Diario de Productos" como una cuenta de "Camisetas". La primer diario es financiero, mientras que los dos últimos son analíticos. De esta manera se va a poder observar las ventas realizadas por Cristian y las Ventas totales realizadas del producto Camiseta.

Los asientos ya son entidades bastante complejas porque no solo permiten aparecer en varios diarios al mismo tiempo y con diferente numeración, sino también porque permite tener información del tipo de movimiento. Un tema escabroso pero no imposible de abordar son las cuentas asociadas a los diferentes diarios. En general éstos son los que marcan

Entonces, ya se pueden imaginar como trabajar con las facturas? Bien, el secreto está en crear tantos diarios como vistas de movimientos se quiera realizar. Sencillo? No tanto, porque puede que necesiten agregar diarios a las facturas ya que necesitan realizar muchas vistas, Pero no asustarse, todo puede arreglarse por el lado de la programación.

Eso es todo por ahora. Espero en la próxima entrega trabajar ya con automatización de procesos.

Licencia OpenERP

2010-12-04T01:10:00.001-03:00

Lo poco que voy a comentar ahora es el resultado de leer detalladamente las licencias del desarrollador de OpenERP. Las mismas puedes leerlas aquí.

Para OpenERP existes dos licencias que se pueden aplicar.

Empezando por el servidor de openerp nos encontramos con la famosa y bien querída GPL V3. Ésta licencia no existe en español, nadie la ha traducido en términos oficiales y la razón principal es la pérdida del espíritu de la licencia al traducirla. Es por ello que no es bien vista la traducción, y si se tiene que defender legalmente solo queda hacerlo en ingles. No quiero entrar en detalles muy técnicos, pero la licencia se aplica a software libre. Asegura que todo software liberado podrá ser compartido y modificado por la comunidad (usted es parte de esa comunidad) sin necesidad de retribuir a nadie. Los autores mantienen su caracter de tal y eso nunca se pierde. O sea, los autores ceden el derecho de copia y modificación, pero nunca la autoría. [traducción no oficial de la licencia GPL al español] Esta licencia también protege a las extensiones y al cliente GTK.
En cambio el cliente web no tiene esa misma libertad. Tal como dice la documentación, la licencia se conoce como "OpenERP Public License", que es equivalente a la Mozilla Public License (MPL) v1, pero con algunas modificaciones. La MPL es una licencia también para software libre, pero libera a los desarrolladores y usuarios explotar económicamente el software. Las salvedades que hablabamos corresponde a promocionar a las empresas que desarrollaron el soft imposibilitando eliminar sus logos de las páginas generadas por el cliente web. En si, se puede quitar algunas, pero no todas. Lean bien el documento que dejé al principio si están interesados en hacer algo equivalente.

Si no sabes que significa software libre, aquí transcribo las cuatro libertades del software libre:

Libertad 0: Ejecutar el programa con cualquier propósito (privado, educativo, público, comercial, militar, etc.)
Libertad 1: Estudiar y modificar el programa (para lo cual es necesario poder acceder al código fuente)
Libertad 2: Distribuir el programa de manera que se pueda ayudar al prójimo
Libertad 3: Distribuir las versiones modificadas propias

Las licencias que dicen ser de software libre deben garantizar estas cuatro libertades.

Enterprise Resource Planning o simplemente ERP

2010-12-02T23:12:00.002-03:00

La segunda guerra mundial generó muchas de las tecnologías y metodologías que usamos actualmente. Quizás deba decir que todo surgió durante la revolución industrial, pero en aquellas épocas los conceptos no cerraban correctamente y apenas solucionaban problemas comerciales de formas muy intuitiva. Con la llegada definitiva de la matemática a la milicia y su posterior aplicación en los negocios, se logró unificar criterios ya con un sentido lógico y matemático adaptándolos a una nueva era. Y justo a tiempo llegó la computadora para automatizar las tareas que implicaba esta nueva forma de pensar.

Podemos identificar varias etapas en durante el proceso de automatización. Comenzando en la década del 50 al 80 el estudio se centraba el flujo de los materias o logística. Incluso las empresas que todavía no adaptaron todos los avances de esa época mantienen estos procesos sub-optimizados e inclusive precariamente conectados los diferentes interesados en el proceso. Algo tan sencillo como la disponibilidad de un producto ya es un problema difícil de manejar si no se tiene una comunicación interna pulida, y no hablar de la relación entre sus proveedores y clientes.

Las computadoras se introdujeron durante la década del 60 en lo que se conoció como Material Requirement Planning (MRP) ó Planificación de los requerimientos de material. La traducción es un tanto desagradable, y preferiría llamarlo Administrador de Requerimientos de Materiales. Eso es lo de menos, lo importante es que se empezó a registrar y administrar los pedidos, ventas, entradas y salidas de los materiales a través de un sistema automático.

En la década del 80 ya el cambio se centró en aumentar la robustez de éstos sistemas y en los 90 nacieron los primeros ERP donde centraban todo el proceso de una empresa en una computadora.

Los procesos pueden ser muchos, pero podemos nombrar algunos pocos como son Administración de Persona, Administración de Clientes y Proveedores, Administración de Stock, Administración de Proyectos, Administración Financiera, etc... todo en una única aplicación e interactuando todas las partes entre si. Justamente esa interacción hace difícil su configuración y posterior puesta en marcha. [1]

En la Argentina podemos encontrar varios ERP, desde los históricos Tango y Bejerman, pasando por EasySoft y terminando en el todopoderoso SAP. No vengo a promocionar ninguna de éstas, ni mucho menos. La realidad es que yo trabajo con OpenERP por una razón muy simple, libertad. Tanta libertad para el cliente como para el proveedor. En que sentido? En el sentido más puro de la palabra. El cliente puede elegir el proveedor y el proveedor puede elegir al cliente. Somos varios en argentina que estamos implementando este tipo de soluciones. Thymbra es la más antigua y con más experiencia y seguro que soy injusto con otras. Y muchos otros estamos haciendo los primeros pasos. Lo que si es verdad que el código de esta solución tiene una licencia sin costo, y cualquiera puede intentar instalarlo y hacerlo funcionar. Pero si necesita ayuda pueden contar con los cuantos que estamos dispuesto a ayudar. Un primer paso sería contactarse con el grupo de openerp-argentina de google y buscar algún proveedor, no de software, sino de soporte técnico o instalación.

Si surgen preguntas como: puede el OpenERP satisfacer todas mis necesidades? La respuesta es; si no puede hoy, podrá mañana y si contrata programadores puede hacer que se satisfagan mucho antes.

En mi empresa, Moldeo Interactive CT, nos estamos centrándonos en ayudar a instalar, dar soporte técnico como también un poco de docencia. También tenemos nuestros proyectos relacionados, como una nube de servicios OpenERP, osea un lugar centralizado en la WEB donde pueden acceder varias empresas a su propio ERP. También estamos iniciando ya proyecto más avanzados como lectores de código de barra y QR, y quizás a mediados del año que viene logremos liberar el código para reconocimiento de rostro para control de personal. Eso si sería todo un chiche.

Terminando, existen muchas razones para pasarse a OpenERP. La mejor de todas es la libertad. Quizás sea más barato, aunque no lo aseguro. Pero lo más importante es su flexibilidad y su futuro.

Referencia: [1] E-bussines and ERP: Transforming the Enterprise.

Llenando formularios en OpenERP

2010-12-01T22:13:00.001-03:00

En general, las cosas en OpenERP son Listas y Formularios. Las listas no son más que una lista de cosas que puedes ver o editar, mientras que los formularios son solo de edición. Digamos, hasta aquí no hay mucho secreto. Pero si puede ser difícil de entender como llenar los formularios.

Me gustaría comenzar con los botones que nos podemos encontrar en un formulario. La imagen a continuación muestra un formulario tradicional de persona o partner en el entorno web.

Empezando de arriba para abajo podemos encontrar el nombre del tipo de formulario que estamos editando un partner en este caso. A su derecha se encuentran los botones Buscar, Formulario, Calendario, Gantt, Gráfico y Proceso. Estos botones identifican un cambio de estado del entorno. Que quiero decir con esto? Bue! Simplemente que cambia la pantalla. Si presionan alguno de ellos van a perder lo que cargaron y van a otra parte. En otra entrada describiré en más detalle cada punto.

Bajemos una linea y nos encontramos con tres botones Guardar, Guardar & Editar y Cancelar. Estos guardan lo que hemos hecho o lo cancelamos. El primero y el último te envían a la lista de este tipo de entradas, mientras que el del medio permite seguir editando. Estos botones están orientados a cambiar el estado de la entrada del formulario. Y a su derecha podemos ver algo extraño, ya que uno no esperaría encontrar signos menos y mas y otros números. En verdad estos controles no son extraños. Simplemente nos permite navegar en las diferentes entradas de este mismo tipo de entradas. Uno esperaría presionas << e ir a la primera entrada del partner, por ejemplo. Recomiendo experimentar, pero sin antes haber presionado Guardar & Editar para no perder los cambios.

Luego empieza el formulario de verdad. Los formularios tienen una estructura jerárquica. Entradas principales y entradas secundarias. Dentro de estas entradas podemos distinguir las obligatorias y las no obligatorias. Obligatorias significa que no se puede grabar un formulario sin antes haber llenado la entrada. Éstas son de color celeste claro y se vuelven rojas si no están bien cargadas. Las otras son de color blanca.

Las entradas secundarias se distribuyen en solapas dentro del
formulario. Por ejemplo el Partner tiene las solapas: General, Venta y
Compra, Historial, Notas, Contabilidad y Avisos. Recomiendo por ahora
revisar todas las entradas antes de seguir con el formulario.

Van a encontrar un ícono con forma de discorígido con una flecha apuntandole enalgunas entradas.

Éste ícono indica que hay que grabar el formulario antes de seguir con esa entrada (con presionar el ícono es suficiente). Las entradas con estas flechas son listados. Por ejemplo el partner puede tener varios contactos asociados, y llenando esta parte del formulario se puede ir generando más contactos para un solo partner.

Otró ícono importante es el de la carpeta, que siempre está acompañado con el de la lupa. Éste esta asociado a entradas del tipo referencias. Esto significa que debería existir la entrada en la base de datos para poder referenciarlo. Si no hay referencia y se quiere asignar se puede optar por escribir parte del nombre y cambiar de entrada o que presionar sobre la lupa. Si el sistema encuentra una única referencia con ese nombre la asigna, sino lista las posibles. Esto puede verse nuevamente en la carga de un partner, que cuando se escribe "Arg" en el país aparecen Argelia y Argentina en una lista; en cambio si se escribe "Argen" se asigna directamente "Argentina". Ahora, si se quiere ir a la referencia, tanto para ver más detalles o para editarla, se debe presionar sobre la carpeta.

Hay que tener en cuenta que según se habiliten o deshabiliten módulos
puede aparecer o desaparecer entradas.

Servicio OpenERP en Intenet

2010-12-01T21:29:00.000-03:00

En mi búsqueda de nuevas oportunidades y escuchando las recomendaciones de mis pares he decidido abrir un sitio OpenERP en Internet. Por ahora el acceso es restringido, pero que quieran probarlo no duden contactarse conmigo.

Y por supuesto voy a seguir publicando en el blog temas de OpenERP que pueda interesarle a los novicios del tema.

Reconocimiento de Rostros con OpenCV

2010-11-06T07:54:00.000-03:00

En esta ocación me tomé un tiempo para estudiar como capturar video usando OpenCV y me atrevía ir un poco más (y no mucho más) para ver como reconocer rostros. El código lo hice en Python usando el módulo/wrapper de OpenCV y con la ayuda de pycam, un código que encontré en googlecode.

Capturar de la cámara.

Las funciones que se usan se encuentran en el módulo highgui de opencv. La que configura la cámara es la función cvCreateCameraCapture, que devuelve un objeto tipo cvCamera. Luego se captura la imagen con la función cvQueryFrame. Aquí un pequeño ejemplo de un código que solo captura 30 frames por segundo y lo muestra en un ventana.

"""
from opencv.highgui import cvCreateCameraCapture, cvQueryFrame
from opencv.adaptors import Ipl2PIL

import pygame

from pygame.locals import *

import sys

camera = cvCreateCameraCapture(0)

def get_image():
im = cvQueryFrame(camera)
return Ipl2PIL(im)

fps = 30.0

pygame.init()

window = pygame.display.set_mode((640,480))

pygame.display.set_caption("WebCam Demo")

screen = pygame.display.get_surface()

while True:
   events = pygame.event.get()
   for event in events:
   if event.type == QUIT or event.type == KEYDOWN:
   sys.exit(0)
   im = get_image()
   pg_img = pygame.image.frombuffer(im.tostring(), im.size, im.mode)
   screen.blit(pg_img, (0,0))
   pygame.display.flip()
   pygame.time.delay(int(1000 * 1.0/fps))
"""

En este código podemos ver que no solo estoy usando el módulo opencv sino tambien pygame. Éste último permite crear una ventana y renderear la imagen capturada. En el código podemos observar que existen varias partes que no tengo tiempo de discutir como es el loop infinito con captura de eventos de pygame y cómo realiza el rendering usando funciones de transformaciones del buffer. Ahora solo quiero concentrarme en OpenCV.

Con esta parte del código ya podemos ver cómo se selecciona la cámara 0 y luego se toma la imagen y se la transforma en un formato PIL. La función get_image es la que modificaremos para realizar llamará a las próximas dos funciones que permitirán donde está en la imagen un rostro.

"""
def detectObject(im):
   gray = cv.cvCreateImage( cv.cvSize(im.width,im.height), 8, 1 )
   small_img = cv.cvCreateImage(cv.cvSize(cv.cvRound (im.width/image_scale),
   cv.cvRound (im.height/image_scale)),
   8, 1)
   print small_img.width, small_img.height
   cv.cvCvtColor( im, gray, cv.CV_BGR2GRAY )
   cv.cvResize( gray, small_img, cv.CV_INTER_LINEAR )
   cv.cvEqualizeHist( small_img, small_img )

   cv.cvClearMemStorage(storage)

   faces = cv.cvHaarDetectObjects(small_img, cascade, storage,
   haar_scale, min_neighbors, haar_flags,
   min_size);
   return faces
"""

En esta primera función se realiza todo lo necesario para identificar los rostros usando un detector de Haar. Si quieres conocer más de esta método aquí encontré una buena referencia.

Muy bien, este método require para ser increíblemente rápido que se reduzca la imagen tanto en tamaño como en cantidad de colores (a grises!). Luego se utiliza el detector de Haar para reconocer las caras.

El detector de Haard necesita previamente un par de configuraciónes para conocer el patron que se requiere para detectar diferentes objetos. Esta información es:

"""
cascade_name = "haarcascade_frontalface_alt.xml"

cascade = cv.cvLoadHaarClassifierCascade(cascade_name, cv.cvSize(1,1))

storage = cv.cvCreateMemStorage(0)

min_size = cv.cvSize(20,20)
image_scale = 2.4
haar_scale = 1.1
min_neighbors = 3
haar_flags = 0
"""

El cascade_name es un path a un archivo que lo pueden bajar de aquí. Con esto pueden crear el clasificador en cascade para el método Haar. Éste clasificador necesita conocer el tamaño en que fue entrenado el archivo, en este caso lo definimos en 1x1 pixels. Construimos un espacio de memoria para que pueda trabajar el clasificador (storage) y definimos los tamaños mínimos del rostro a detectar en pixels (min_size) y el factor de reducción de la imagen a clasificar (image_scale). El factor de reducción de la ventana para la clasificación (haar_scale) y la cantidad de vecinos que se agrupan para identificar un rostro (min_neighbors) son parámetros del clasificador. Con éstos hay que jugar para poder mejorar el rendimiento de la busqueda. Las banderas (haar_flags) por ahora solo acepta un solo valor, con lo que no recomiendo cambiar nada de todo esto. Si quieren ver en detalle estos valores puede ir aquí.

Una vez que se configura esto y se definen la función de reconocimiento solo falta dibujar la caja con el rostro.

"""
def detect_and_draw(im):
   faces = detectObject(im)
   if faces:
   for r in faces:
   print "Una cara en (x,y) = (%i,%i)" % (r.x*image_scale,r.y*image_scale)
   pt1 = cv.cvPoint( int(r.x*image_scale), int(r.y*image_scale))
   pt2 = cv.cvPoint( int((r.x+r.width)*image_scale), int((r.y+r.height)*image_scale) )
   cv.cvRectangle( im, pt1, pt2, cv.CV_RGB(255,0,0), 3, 8, 0 )
   return im
"""

Si integramos el código en forma correcta podemos llegar a obtener el siguiente resultado.

Iniciandose en OpenERP para Argentina

2010-11-02T10:29:00.001-03:00

Estos últimos días me concentré en instalar y configurar una herramienta ERP opensource para una empresa y para mi Cooperativa de Trabajo en formación. Su nombre es OpenERP aunque previamente se conocía como TinyERP. La herramienta es desarrollada por OpenERP S.A. y se maneja bajo la licencia AGPL (http://www.gnu.org/licenses/agpl.html). Si quieres conocer el modelo de negocio de OpenERP puedes ir a (http://www.openerp.com/products/business-model)

Bien, ya definiendo las bases del modelo de negocio ahora continuo con la parte más técnica. Empiezo desde el principio: la instalación.

OpenERP esta accesible en plataformas Debian y Ubuntu desde hace poco tiempo. Es más, solo lo puedes encontrar en la versión inestable de Debian. Ubuntu, al tener otra filosofía sobre la estabilidad ya lo tiene incorporado. Si tienes una de estas plataformas directamente puedes realizar un "aptitude install openerp-server". En caso contrario te recomiendo obtener el código fuente.

Esta herramienta depende principalmente de Python-2.5 y PostgreSQL. Una vez instalado todo habrá que preparar la base de datos. Eso se hace creando un usuario postgresql y creandole una base de datos. Esto último es necesario porque sino los clientes Postgresql no van a poder conectarse.

Una vez que se tenga todo instalado y corriendo se va a necesitar un cliente. OpenERP tiene dos clientes oficiales: openerp-cliente, basado en GTK y openerp-web basado en HTML. Ambos se conectan por Socket y XML-RPC al servidor. El primer cliente puede bajarse de los repositorios de Debian y Ubuntu, en cambio el segundo solo puede instalarse por easy_install. (http://doc.openerp.com/install/linux/web/index.html) También se puede configurar para que pueda ser accesido desde la web.

Una vez instalado el cliente es momento de configurar las tablas para luego configurar el sistema. Eso se puede hacer desde ambos clientes en la opción crear base de datos.

El puntos más conflictivo de la instalación es la configuración del postgresql. Confunde mucho los permisos de usuario y las claves, ya que tenemos que manejarnos con al menos 5 pares: El administrador del sistema unix, el administrador del postgresql, el usuario de la base de datos del openerp, el usuario administrador del openerp y el usuario del openerp. Lo mejor es identificar estos usuarios, eso significa tener una lista de ellos y saber cuando usar sus claves. Eso si, el administrador de la base de datos postgresql y el usuario de la base de datos del openerp en postgres no requieren de clave! Y esa configuración viene por defecto. Traten de no cambiar nada de eso. Debería funcionar. Cualquier cosa pregunten.

Ya todo instalado hay que empezar a configurar el OpenERP para funcionar con nuestra empresa. Para ello podemos instalar los módulos de argentina (https://launchpad.net/openerp-argentina). Para la instalación es necesario usar las herramientas de launchpad. Las instalamos primero para luego ejecutar el comando de descarga:

$ sudo aptitude install bzr
$ bzr branch lp:openerp-argentina

Esto nos dejo en el directorio donde estemos parado un directorio con los módulos a activar. Esos se copian en el directorio de módulos de openerp, pero eso hablaremos en el próximo capítulo.

Instalando Community Engine (3)

2008-12-08T23:08:00.001-02:00

Luego de una larga investigación he llegado a la conclusión que todos mis problemas se debían a un detalle pasado por alto. El Community Engine necesita de Rails 2.1.0. Y por supuesto esto trae varios problemas.

En principio, aparenta haber varias incompatibilidades, entre ellas el manejo de idiomas. Aunque muchas funcionalidades nuevas en el Rails que no son aprovechadas en el Community Engine la situación no es drástica. Habrá que esperar un par de meses para que Community Engine esté listo para 2.2.0 ya que existe un branch del engine donde ya hay gente trabajando.

Ahora, ¿cómo instalar entonces el Rails viejo para que todo empiece a funcionar? En principio hay que empezar de cero y cambiar algunos comandos.

En el paso 1 el comando

$ sudo gem install rails

hay que cambiarlo a

$ sudo gem install rails --version 2.1.0

Ahora eso no es suficiente. El plugin engines también hay que desactualizarlo, pero de otra manera. El comando

$ script/plugin install git://github.com/lazyatom/engines.git

sigue en pie, pero hay que ejecutar algo más en el directorio vendor/plugins/community_engine/, el comando:

$ git checkout -b 2.1.0

Con estos cambios ya podemos seguir adelante.

Paso 12) Generamos los pasos del esquema de Community engine.

$ script/generate plugin_migration

Paso 13) Generamos el esquema de la base de datos.

$ rake db:migrate

Paso 14) Probamos la instalación. Los siguientes comandos, ejecutados siempre uno detrás del otro, ejecutan test funcional y de unidad de cada característica del sitio.

$ rake test

$ rake community_engine:test

Yo he logrado hacer funcionar el sistema con unos 16 errores. Ahora, si llegan a los ~200 errores más vale que reevean todos los pasos.

Paso 15) Ejecutar el Server.

$ ./script/server

Paso 16) Acceder a la página web principal.

$ http://localhost:3000/

A partir de ahora es cuestión de experimentar. En la próxima entrada me voy a concentrar en los roles. Por lo que he leído ya están implementados y pueden modificarse directamente en la base de datos (link). Tengan en cuenta que esto permite definir permisos y así limitar el acceso a la información en el sitio. Esto tiene como consecuencia inmediata una independencia de la interface con las reglas de negocio. Espero que vean la utilidad en mi próxima entrada.

Referencias:

http://www.communityengine.org/documentation.html

Inososhi - Otro framework para redes sociales

2008-12-08T18:49:00.000-02:00

Insistiendo en redes sociales, y también sobre ruby (ruby on rails) he encontrado una alternativa a Community Engine. Fue relativamente fácil de instalar ya que aparenta estar realmente actualizada. El único problema existe en que no tiene suficiente flexibilidad, o por lo menos no he encontrado suficiente documentación.

El sitio oficial es: http://portal.insoshi.com/
Y algunos tips necesarios para la instalación es: http://www.sphinxsearch.com/forum/view.html?id=1419 que va a permitir instalar sphinxsearch necesario para inososhi en debian.

Instalando Community Engine (2)

2008-12-05T10:37:00.000-02:00

Hoy voy a mostrarles como instalar la extensión para armar redes sociales a partir de lo escrito en la entrada anterior. Partimos del sexto paso.

Paso 6) Instalar el plugin. Existe varias formas de instalar la extensión, todas descriptas en el documento oficial. Pero por una cuestión de gusto y comodidad voy a elegir la instalación por git.

Nos paramos en el directorio principal donde tenemos instalado nuestro sitio y ejecutamos el siguiente comando.

git clone --depth 1 git://github.com/bborn/communityengine.git vendor/plugins/community_engine

En unos pocos minutos tenemos los archivos de la extensión en vendor/plugins.

Paso 7) Configurar la base de datos. Solo hay que tocar el archivo config/database.yml , que condiciones de prueba no es necesario tocar. Por defecto usa una base de datos sqlite que si bien no es un motor de base de datos muy poderoso es suficiente para almacenar las entidades de una red básica de unas 100 personas. Se pueden usar otras bases de datos como por ejemplo MySql y Postgresql. Más información puede verse aquí.

Paso 8) Deshacerse de la página principal. Para acceder a la página del sitio comunitario hay que eliminar el public/index.html (Digo borrarlo, moverlo, cambiar de nombre, ...)

Paso 9) Habilitar el sitio comunitario. Es momento de habilitar el sitio comunitario agregando parámetros al archivo de configuración config/environment.rb . Los cambios son los siguientes:

Debajo de

require File.join(File.dirname(__FILE__), 'boot')

agregar la linea

require File.join(File.dirname(__FILE__), '../vendor/plugins/engines/boot')

Y debajo del texto (o parecido, lo importante es el config.plugins)

# Only load the plugins named here, in the order given. By default, all plugins
# in vendor/plugins are loaded in alphabetical order.
# :all can be used as a placeholder for all plugins not explicitly named
# config.plugins = [ :exception_notification, :ssl_requirement, :all ]

hay que agregar la linea

config.plugins = [:engines, :community_engine, :white_list, :all]
config.plugin_paths += ["#{RAILS_ROOT}/vendor/plugins/community_engine/engine_plugins"]

y por último, hay que agregar al final del archivo, luego del

end

la siguente linea que va a levantar la configuración del plugin.

require "#{RAILS_ROOT}/vendor/plugins/community_engine/engine_config/boot.rb"

Paso 10) Configurar la URL. Eso se hace retocando los archivos development.rb, test.rb, y production.rb en el directorio config/environments . Cada uno de estos archivos configura el entorno donde estamos ejecutando nuestro sitio, permitiendo tener tres sitios diferentes según sea de desarrollo, de testing o el sitio de producción. Entonces hay que agregarle la siguiente linea:

APP_URL = "http://localhost:3000"

Como estoy testeando la URL donde correrá el sitio indica que va a ser mi máquina y en el puerto 3000.

Paso 11) Configurar las rutas. La verdad que no tengo idea de que tratan esas rutas, pero si hay que hacerlo, hagamoslo. Al final, antes de las rutas definidas por defecto, en el archivo config/routes.rb hay que agregar:

# Add this after any of your own existing routes, but before the default rails routes:
map.from_plugin :community_engine
# Install the default routes as the lowest priority.
map.connect ':controller/:action/:id'
map.connect ':controller/:action/:id.:format'

Paso 12) Migrar el sitio rails. Ahora el sitio está configurado en la base de datos para funcionar en el sitio de prueba de rails, con lo que hay que adaptar todo al sitio comunitario. Para ello ejecutamos el comando:

script/generate plugin_migration

ERROR!: Puede que apareciera el siguiente error en la ejecución

uninitialized class variable @@default_error_messages in ActiveRecord::Errors

No pude pasar de este error. Espero en la próxima entrada haber resuelto este paso. (Me deprimí)

Instalando Community Engine (1)

2008-12-04T10:43:00.000-02:00

Community Engine es un plugin de Ruby On Rails. En otras palabras, es una extensión de Redes Sociales para un Framework Web programado por completo en Ruby. Y Ruby, es un lenguaje de programación derivado de SmallTalk, con lo que quienes saben la implicancia de la programación orientada a objeto pura entenderán que tiene muchas prestaciones a la hora del diseño y la extensibilidad del software. Pero no quiero hablar de esto, sino del hecho de la instalación. Luego si tengo tiempo podré describir en detalle que se puede hacer con esta herramienta tan poco conocida en la web, ya que Ruby está en la sombra de Python y PHP.

Quiero destacar, antes de empezar, que la instalación está pensado en Debian y que esta puede cambiar dentro de unos pocos meses, siempre pensando que cambiará hacia la sencillez.

Paso 0) Precondición. hay que tener instalado los paquetes ruby1.8, rubygems1.8, libopenssl-ruby que se encuentran en los repositorios Debian.

Paso 1) Instalar el ruby-on-rails. En si es un paso sencillo gracias a Gems.

$ sudo gem install rails

Paso 2) Creando sitio Ruby on Rails. Ahora, bajo los manuales de rails, solo es necesario ejecutar en un directorio donde tendremos el código de nuestro sitio el siguiente comando:

$ rails $HOME/mi_sitio

donde mi_sitio es el nombre del directorio donde ustedes quieren que se almacene el código fuente resultante.

Sino encuentran el ejecutable rails deberían solucionarlo con una de las siguientes opciones:
Agregar el directorio /var/lib/gems/1.8/bin al PATH del sistema.
Realizar un link a un directorio de los ejecutables (~/bin/ , /usr/local/bin , /usr/bin ; en orden de preferencia y según si se va a instalar para un solo usuario o para todos)

Paso 3) Ejecutando del servidor. Terminada la construcción del código fuente del sitio ya está todo listo para poder testear un sitio básico ejecutando:

$ ruby script/server

Aquí se pueden encontrar con que la versión de gems no es la adecuada. Si es así les recomiendo ejecutar el siguiente comando:
$ sudo gem install rubygems-update
para luego actualizar el gems con el comando:
$ sudo /var/lib/gems/1.8/bin/update_rubygems
Ojo! Este error implica reinstalar el rails (volver al paso 1)

Paso 4) Veamos el sitio! Ahora nos queda acceder en la dirección http://localhost:3000/ desde nuestro navegador favorito. Si está realizando la instalación en otra máquina debería colocar el nombre de la misma en vez de localhost.

Podemos leer un poco lo que dice la página de presentación para informarnos un poco más de lo que estamos haciendo para luego seguir con la instalación.

Paso 5) Instalar el plugin engines. Esto nos va a permitir instalar plugins en nuestro sitio.

$ script/plugin install git://github.com/lazyatom/engines.git

Paso 6) Instalar el plugin Community Engine. Ahora podemos instalar el plugin para armar nuestra comunidad.

Este paso lo vamos a dejar para la próxima entrada porque ya estoy muy cansado el día de hoy.

Referencias:

Presentaciones con Latex (Parte I)

2008-08-13T19:20:00.000-03:00

Latex es un lenguaje de documentación que no cumple con la filosofía WYWISING, sino con la filosofía "El contenido es primero". En este sentido la idea es describir el contenido, luego la presentación se resuelve de forma automática. Esto se aproxima múcho a usar el World de M$ con hojas de estilo. La diferencia mayor es que el contenido debe editarse con un editor de texto plano, como el notepad, el vim u otro.

Aunque Latex sirve para editar cualquier tipo de documentos imprimible, aquí voy a presentar el beamer, un estilo de documentos para realizar presentaciones.

En principio para empezar es recomendable empezar con una plantilla. La siguiente es con la que yo siempre empiezo, donde trabajo con el idioma en castellano y una presentación común. Luego agrego y modifico según las referencias de beamer.

\documentclass[utf8]{beamer} \usepackage{beamerthemesplit} \usepackage[utf8]{inputenc} \usepackage{multimedia} %% Theme %% \usetheme{Frankfurt} %% Info %% \title{Título de la presentación} \author[tu email]{Tu nombre completo} \date{Donde estas presentando\\\today} \institute{Y el instituto donde perteneces} %% Document %% \begin{document} \frame{\titlepage} \section[Outline]{} \frame{\tableofcontents} \section{Introducción} \begin{frame} \frametitle{La introducción de la presentación} \begin{itemize} \item Primer punto de la introducción \item Sengundo punto de la introducción \item y el tercero \end{itemize} \end{frame} \end{document}

Para entender un poco más de latex, hay que identificar algunos elementos de sintaxis. El primer elemento y el más sencillo de entender es % que son comentarios. El resto de los elementos podemos identificar secciones empiezan con \begin y terminan con \end, y el nombre de las secciones se encuentran entre llaves "{}".

Cómo cambiar contenidos de archivos con el SED

2008-03-18T16:27:00.000-03:00

El sed es una de las herramientas de edición basadas en "corrientes" de caracteres. ¿Qué es eso?
Bue, una aplicación que es capaz de modificar archivos en batch de forma muy sencilla. ¿Y a quien le gustaría hacer eso? Quienes necesiten editar gran cantidad de archivos con alguna tarea repetitiva ¿Cómo cual? Y cambiar una palabra en todos los archivos que están en un directorio. Y éste pequeño tutorial es para mostrar cómo realizar esta tarea. Aquí vamos.

Nota 1: Si eres usuario de windows, te recomiendo bajarte el cygwin donde podrás encontrar esta herramienta y muchas más. Todas gratuitas... o mejor dicho: libres!

Nota 2: Antes de empezar quisiera advertirte que si nunca oíste hablar de "expresiones regulares" te recomiendo que leas algo en la red. Podrías buscar una descripción en Wikipedia.

Vamos por pasos, primero definimo la expresión regular que describirá la modificación que queremos realizar en cada uno de los archivos. En éste caso queremos cambiar la palabra "librería" por "biblioteca". Eso en expresiones regulares puede escribirse como:

s/librería/biblioteca/

Y puede ejecutarse con el siguiente comando de sed:

sed -e 's/librería/biblioteca/' MiArchivo

Eso es lo fácil, ahora hay que modificar el archivo, porque ésto solo va a devolver en la consola el archivo modificado. Y nada de redireccionar la salida directamente a 'MiArchivo' porque perderás tu querido archivo. Lo mejor es usar un archivo temporal:

sed -e 's/librería/biblioteca/' MiArchivo > $$.tmp ; mv $$.tmp MiArchivo

Si lo que nos gustaría hacer es modificar todos los archivos dentro de un directorio hay que utilizar la herramienta find que nos permitirá ejecutar un comando a cada archivo. El problema que tenemos aquí es que hay dos comandos a ejecutar y escribir esto en el find es un tanto complicado, con lo que una excelente opción es escribir un sencillo script que nos resolverá futuros problemas:

#!/bin/bash
#-- recomiendo almacenar el archivo en ~/bin/overwrite
#-- darle permisos de ejecución con chmod +x ~/bin/overwrite
#-- y agregar a ~/bin a la variable PATH con
#-- echo export PATH=$PATH:~/bin >> ~/.bashrc
#-- Salir de la seción y volver a entrar para que los comandos
#-- almacenados en el directorio ~/bin puedan ejecutarse sin
#-- hacer malavares con los nombres de directorios.

file=$1
shift
$* < $file > /tmp/$$.tmp
chmod --reference=$file /tmp/$$.tmp
chown --reference=$file /tmp/$$.tmp
mv /tmp/$$.tmp $file

Este nuevo comando nos va a permitir ejecutar el mismo comando sed pero mucho más corto

overwrite MiArchivo sed -e 's/librería/biblioteca/'

Ahora la modificación de archivos dentro de un directorio se puede hacer fácilmente con el comando find de la siguiente manera:

find ./ -type f -exec overwrite {} sed -e 's/librería/biblioteca/' \;

Ésto ejecuta el comando a todos los archivos, que no son directorios y otras cosas raras, que se encuentran en directorio local y todos sus hijos. Notar el {} que es una macro del nombre del archivo donde ejecutar el comando, y el \; indica el fin del comando.