Desde hace un tiempo estoy metido en una implantación de OpenERP en una empresa internacional, la implantación requería multicompañía y multidivisa, el siguiente post lo escribí en el blog de Domatix para documentar el proceso de configuración y funcionamiento de multidivisa con multicompañía en OpenERP.

OpenERP permite trabajar con múltiples divisas, la forma en la que permite trabajar con multidivisa es asociando una moneda principal para la compañía y un listado de monedas con su tasa de cambio para cada fecha.

Se pueden definir tarifas para cada moneda y usarlas en pedidos y facturas, en los pedidos se indicará la tarifa de la moneda que queramos utilizar, y en la facturación podremos usar la misma moneda o hacer el cambio de divisa. Al validar la factura los movimientos contables se generarán en la moneda principal de la compañía con el cambio divisas actual almacenado en el sistema.

En este artículo se muestra como configurar y trabajar con varias monedas.

Enlazo la entrada del blog de domatix, escrito por Nacho, donde cuenta como fue nuestra asistencia con Domatix en las jornadas.

Una de las mejoras esperadas en la versión 6 de OpenERP era el soporte multiempresa o multicompañía incluido en el módulo base. En este artículo vamos a ver como configurar la multicompañía y como restringir el acceso de los usuarios.

Lo primero que necesitamos para trabajar con OpenERP en multicompañía es añadir a nuestro usuario el grupo “Useability / Multi companies”, de esta forma podremos ver los campos referentes a la multicompañía.

Si nuestro usuario tiene asignado este grupo podremos ver el menú /Administración/Compañías, en la ventana de Compañías podremos dar de alta las compañías.

Las diferentes compañías se pueden crear en OpenERP en una estructura de jerárquica. Así, si queremos crear un grupo de empresas llamado A formado por las empresas B y C primero crearemos la compañía A y luego al crear las compañías B y C completaremos el campo compañía padre con la compañía A.

En el menú compañía árbol de compañías podemos ver esta estructura.

Una vez creadas las compañías tenemos que configurar el acceso a los diferentes documentos, pero antes tenemos que tener claro como funciona el control de acceso a cada compañía. Cada usuario tendrá una lista de compañías a las que se le permite el acceso, y entre esas compañías una será la compañía actual.

Si vamos al menú de usuarios podemos ver la compañía actual del usuario:

y la lista de compañías a las que tiene acceso:

De esta forma cuando un usuario se conecte a OpenERP lo hará con una compañía, y no tendrá acceso a los datos de otras compañías aunque esté en su lista de compañías autorizadas.
Importante: Hay que tener cuidado de no trabajar con el usuario admin en multicompañía, ya que este usuario se salta los controles de acceso multicompañía. Así que lo mejor es cuando se cree una compañía crear un usuario administrador de esa compañía con el que hacer toda la configuración.

Ahora que tenemos claro como funciona el control de acceso podemos ver las “reglas de registro”. Las reglas de registro se encuentran en el menú “Administración/Seguridad” y nos sirven para definir quien va a tener acceso a cada documento. Por ejemplo con reglas de registro podríamos hacer que los comerciales solo puedan ver los pedidos que han creado ellos mismos.

Esto nos va a servir en un entorno multicompañía para definir que documentos podemos ver, por ejemplo:

• Un pedido de venta lo podrémos ver si no está asociado a ninguna compañía o si esta asociado a nuestra compañía o alguna compañía que esté por debajo en el árbol de compañías:

• Una empresa la podremos ver si no está asociada a ninguna compañía o está asociada a nuestra compañía o alguna compañía por encima o por debajo en el arbol de compañías:

Hasta aquí hemos visto como crear las compañías y dar acceso a usuarios y documentos, todavía quedan problemas por resolver para hacer totalmente funcional el sistema multicompañía.

El primer problema que nos encontramos es que la instalación de muchos módulos no está pensada para la multicompañía, así que los objetos creados automáticamente en la instalación de un módulo, como pueden ser las secuencias de pedidos en la instalación del módulo de ventas, sólo se crean para la primera compañía que se ha creado. Lo ideal sería que la creación de esos objetos se crease mediante un wizard, y poder lanzarlo en cada compañía, pero de momento nos toca crear esos datos a mano para cada compañía.

Aunque podemos definir una estructura de árbol en las compañías, la consolidación de la contabilidad no está contemplada en este sistema, aunque tenemos cuentas contables virtuales, pero no una forma automática de crear todas las correspondencias.

Otro problema que se está planteando en el canal irc de openobjects es como podemos restringir diferentes accesos de un usuario para cada compañía, por ejemplo un usuario que tenga acceso a compras y ventas en una compañía pero solo a ventas en otra compañía. De momento tampoco podemos contemplar esto y la solución sería crear dos usuarios distintos.

Hace un par de días un programador compartió un problema que tenía en el chat, si tienes un campo al que quieres añadir un sufijo que tienes en otro campo, y los dos campos están definidos como traducibles… ¿ como puedes hacer para combinar los dos campos en todos los idiomas disponibles?

Lo primero que tenemos que saber es que cuando llamamos a uno de los métodos del orm en el context le estamos pasando la información del idioma.

Por otro lado tenemos que tener en cuenta que los idiomas disponibles en nuestra instancia de OpenERP se encuentran en ‘res.lang’.

Así cuando hacemos una operación sobre un campo que tiene habilitada la traducción si le pasamos en el context la información del idioma sólo realizará la operación sobre ese idioma, y si no pasamos la información del idioma realizará la operación sobre el primer idioma (por defecto en_US).

Para hacer una operación sobre todos los idiomas en un campo, tendremos que realizar esa operación tantas veces como idiomas tengamos disponibles en ‘res.lang’, pasando en cada iteración el idioma en el context para realizar la operación.

En el siguiente código de ejemplo lo que hago es cambiar el nombre de un producto por nombre-nombre en todos los idiomas, por ejemplo en mi instalación de OpenERP tengo un producto con el nombre en español ‘prueba’ y en inglés ‘test’, después de pasar este código cambia el nombre en español por ‘prueba-prueba’ y en inglés ‘test-test’.

La forma de trabajar de OpenbravoPOS con Openbravo es mediante un ETL que llama a los webservices de Openbravo, para la integración con OpenERP habrán usado este mecanismo, supongo que tomando como base los ETL preparados para Openbravo. Al hacerse mediante ETL implica que los datos tienen que replicarse cada cierto tiempo, copiándose del POS al ERP y viceversa. De esta forma es complicado llevar el control del stock desde el POS, aunque se puede configurar para ejecutar el ETL continuamente y que se vallan actualizando casi en tiempo real. La ventaja al usar de esta forma, con bases de datos independientes conectadas por ETL, es que podemos usar el POS aun sin tener conexión al servidor de OpenERP, y cuando retome la conexión sincronizar los datos.

La ventaja que tiene OpenbravoPOS es que es mas visual, mas cómodo para usar con interfaces táctiles, mucho mas productivo. Como inconvenientes, prácticamente no lo actualizan nada, lo tienen muy abandonado. La comunidad ha hecho cosas que no Openbravo no han añadido al código. Por ejemplo OpenTPV es el fork de los que hicieron la implantación en la cadena de comida rápida “Bocata”, que para restaurantes es mucho mejor, desarrollaron muchas mejoras que Openbravo no han incluido en su código.

Otro inconveniente, por lo menos para mi, es que el código no está tan bien estructurado como OpenERP, es java con swing, y es complicado de extender… por eso han echo los ETL llamando desde fuera de la aplicación, en lugar de llamar a los webservices directamente desde la aplicación.

Como conclusión, lo que le falta al POS de OpenERP es una interfaz táctil mas productiva, en mi opinión no necesita un sistema POS completo, ya que toda el backoffice se puede llevar desde un pc con el un cliente de OpenERP. Para mi la solución óptima sería hacer un cliente especifico para usar con el módulo point_of_sales de OpenERP, que permita ver, crear, modificar y pagar los tickets del pos desde otra interface mas productiva.

Esto parece que es lo que se va a presentar en los Community Days de OpenERP, un POS basado en web, enfocado a ser mas productivo con interfaces táctil. Los inconvenientes del ETL ya no los tenemos, por que se conecta directamente a la base de datos de OpenERP, pero ¿qué pasa si se cae la conexión? Parece que también lo han tenido en cuenta, y haciendo uso de “localStorage” de HTML5 podrá almacenar las operaciones que se realicen fuera de linea y enviarlas cuando se retome la conexión. Y para la conexión con hardware propio de los post lo hará mediante un proxy “HTTP → Puerto Serie”, con lo que se aseguran la compatibilidad con el hardware aun siendo una aplicación web.

Como avance aquí tenéis una captura de pantalla:

La presentación del POS:

Y ahora a esperar que lo presenten la semana que viene.

http://www.jornadasopenerp.com/

Para estas jornadas han puesto un sistema de votación para las posibles charlas o ponencias, si quieres ver las posibles charlas y votar por la que mas te interese puedes verlo en esta web.

http://jornadasopenerp2011.uservoice.com/forums/109421-ponencias-y-charlas-jornadas

Desde Domatix ya hemos confirmado nuestra asistencia y colaboración, una de las charlas ha sido propuesta por nosotros, y si todo sale bien yo seré el ponente. En la charla “OpenERP vs Openbravo” explicare mi experiencia con Openbravo, y los motivos por los que he encaminado mi carrera profesional hacia OpenERP.

Ahora que esta accesible a ver si retomamos lo de traducir la documentación, si quieres empezar puedes ver como colaborar en la traducción en esta entrada http://angelmoya.es/openerp/traduccion-de-la-documentacion-de-open-erp/.

La información de este manual la he sacado del capítulo OpenOffice.org Reports del developer book, puedes consultarlo si algo no queda claro o para ampliar información.

Para añadir un informe en nuestro módulo tenemos que crear una carpeta reports y dentro crearemos el fichero.rml que es el propio informe , otro fichero con la clase python para imprimir el informe, el __init__.py, un fichero xml para la vista, define donde lo vamos a imprimir, y añadiremos la ruta del xml al fichero __openerp__.py del modulo y el import report al __init__.py.

Preparando el informe en OpenOffice

Vamos por partes, lo primero es obtener el informe.rml, vamos ha obtenerlo a partir de un documento de OpenOffice. Vamos a crear en OpenOffice un documento con los la estructura que queramos para nuestro informe, para que OpenERP complete nuestro informe con datos dinamicos tendremos que indicar los objetos que queremos mostrar con etiquetas escritas entre corchetes.

Lo normal es lanzar el informe asociándolo a un objeto desde la vista del grid seleccionando varias instancias o desde la vista para una única instancia del objeto. Para hacer esto tendremos que indicar en nuestro informa que vamos a imprimir los campos repitiendo sobre un objeto.

donde “objects” es el parámetro del que obtenemos el objeto a imprimir de OpenERP y “o” es el nombre que le hemos dado para referenciarlo en el informe.

después de esta instrucción podremos imprimir cualquier campo del objeto sobre el que lancemos el objeto de la siguiente forma

donde “campo” es un campo simple del objeto “o” pasado para ejecutar el informe.

Si uno de los campos del objeto es otro objeto y la relación es one2many podemos imprimir los campos así:

donde “campo1″ y “campo2″ son campos del objeto asociado en el campo “campo_one2many” del objeto “o”.

Para los campos del tipo many2many o many2one, tendremos que iterar, porque el objeto que estamos imprimiendo puede tener varios objetos asociados, esto lo podemos hacer así:

donde “many_ids” es un campo del tipo many2many o many2one del objeto “o”, “many_etiq” es el nombre que le hemos dado para referenciarlo y “campo1″ y “campo2″ son campos del objeto relacionado en el campo “many_ids”.

Una vez tienes has creado el documento, para poder convertirlo en rml hay que guardarlo con la extensión .swx.
Para ver un ejemplo puedes mirar en el modulo sale, el informe sale-order.sxw en addons/sale/report, y para verlo impreso ve al formulario de pedidos de venta y dale a imprimir.

De OpenOffice a RML

Ahora vamos a ver como transformar este documento .sxw a uno .rml. Para hacerlo vamos ha utilizar sxw2rml, si miras en la documentación, a dia de hoy está indicado para la versión 5, ha cambiado un poco para la versión 6 de OpenERP.

En la versión 5 el ejecutable erá tiny_swx2rml.py y se podía encontrar en:

Para la versión 6 se llama openerp_sxw2rml.py y se encuentra en:

Suponiendo que queremos añadir el informe en un módulo que estamos desarrollando al que llamamos “mi_modulo” y tenemos su carpeta en el directorio addons del servidor y nuestro documento de openoffice lo llamamos “mi_informe.sxw” y lo tenemos en la carpeta “reports” de nuestro informe, para convertir nuestro informe a rml trabajando con la versión 6 podemos hacer lo siguiente:

Añadiendo el informe al módulo

Hasta aquí ya tenemos nuestro informe rml, vamos a ver como imprimirlo desde OpenERP. Lo primero que necesitamos es crear el directorio report en nuestro módulo, dentro de este directorio incluiremos el informe rml, opcionalmente el swx para poder modificarlo luego. Necesitaremos también dentro de este directorio un fichero .py que será la clase que generará el report y el __init__.py con el import del fichero anterior. Para incluir el enlace en una ventana determinada tendrémos que crear un xml, en el que indicaremos desde donde lo imprimimos. Por último tendremos que incluir el una línea con “import report” dentro del __init__.py del módulo y incluir el xml en el __openerp__.py. Podemos ver estos archivos tomando como ejemplo el pedido de venta ( sale order), que esta en el módulo sale.

Si miramos el contenido de sale_order.py

from report import report_sxw

class order(report_sxw.rml_parse):
def __init__(self, cr, uid, name, context=None):
super(order, self).__init__(cr, uid, name, context=context)
self.localcontext.update({
‘time’: time,
})

report_sxw.report_sxw(‘report.sale.order’, ‘sale.order’, ‘addons/sale/report/sale_order.rml’, parser=order, header=”external”)

La clase order es el parser, que hereda de report_sxw.rml_parse, y genera el informe, reemplazando las etiquetas por los datos del objeto. En la llamada a report_sxw.report_sxw(…) le pasamos esta clase como parser. El primer parámetro es el nombre del propio informe, el segundo sobre que clase se van a sacar los datos, el tercero es la ruta del fichero rml, y el último indica si queremos imprimir la cabecera, si ponemos “true” imprimirá la cabecera configurada en OpenERP.

Vamos a ver el xml de la vista que indica que se puede imprimir este informe desde la ventana de pedidos de venta, el fichero es sale_report.xml

Por último para añadir estos fichero al módulo tendremos que añadir en el __init__.py del módulo:

en el en el __init__.py del directorio report:

Y en el __openerp__.py, tenemos que añadir el sale_report.xml para que lo cargue con el módulo.

Y con esto ya tenemos el informe metido en el módulo, si quieres probarlo recuerda que tendrás que reiniciar el servidor con la opción -u y el nombre del módulo para recargarlo.