Setting views: To solve this problem (or rather as a good programming practice), we can do the following, both from a Python file and from an XML file:
Launching specific views from a Python file:
Let’s imagine that the action of our wizard creates a series of objects and we want to show the freshly created ids. To do this and after having developed the logic of our function, we can return a dictionary containing an action window as follows:
Community Days de la próxima semana hemos visto que hay una presentación de un nuevo POS tactil para OpenERP.
En este pos vamos a ver las ventajas e inconvenientes, de la integración de OpenbravoPOS con OpenERP.
Y un avance de lo que será el POS tactil de OpenERP.
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 vayan 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.
Y 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.
Desde Domatix, ya confirmamos nuestra asistencia y colaboración. Y una de las charlas, ha sido propuesta por nosotros, de hecho, si todo sale bien yo seré el ponente.
Además, en la charla “OpenERP vs Openbravo” se expondrán las experiencias de algno de los miembros de nuestro grupo con Openbravo.
Y cuales han sido los motivos por los que, sus carreras profesionales se han orientado hacia OpenERP.
Nuestros compañeros de MalagaTic han traducido parte del libro oficial de OpenERP. más concretamente, los capítulos traducidos del libro OpenERP son los de contabilidad, administración y compras/ventas.
A continuación, los ponemos a disposición de todo el que quiera descargarlos para consultarlos. De hecho, cualquier sugerencia o mejora será bienvenida.
De esta manera, a ver si maximizando la difusión conseguimos mejorar la colaboración comunitaria en la traducción de la documentación del inglés.
Tal y como se decidió en las jornadas del año anterior, en las jornadas OpenERP de este 2011, será Pexego el anfitrión de las jornadas, y se celebraran, por tanto, en Galicia. El texto de presentación:
Esta es la cuarta edición del foro de encuentro para la localización española de openerp y para todos aquellos que tengan intereses por descubrir esta potentísima herramienta y todo lo que gira alrededor de ella.
Las jornadas estatales de OpenERP pretenden ser un punto de encuentro entre usuarios, instaladores y programadores de OpenERP y sus objetivos son diversos:
Descubrir su ecosistema mediante charlas o conferencias.
Mostrar algunas de sus características mediante tutoriales
Dar a conocer algunos casos de éxito y modelos de negocio mediante una mesa redonda.
Debatir y activar el desarrollo de módulos de localización/verticalización.
Facilitar el networking entre los asistentes.
En definitiva, compartir, difundir y mejorar el entorno de desarrollo rápido de aplicaciones y gestión integral (OpenObject/OpenERP) basado en una tecnología moderna y libre que nos permita avanzar de forma colaborativa en el uso de las TIC en nuestra sociedad.
Estas son las cuartas jornadas españolas de OpenERP después de las realizadas en mayo de 2010 en Bilbao, en abril del 2009 en Vilanova y en mayo de 2008 en Zaragoza.
¿Cuando?
26 y 27 de Mayo de 2011
¿Donde?Cámara de Comercio Lugo
Avenida Ramón Ferreiro, 18
27002 Lugo, España
982 284 300
A lo largo de este artículo, trataremos la configuración de decimales y separación de miles en OpenERP 6.
Lo primero que tenemos que hacer es (como usuario con suficientes permisos) dirigirnos al menú ‘Administración->Traducciones->Idiomas‘ y escoger el idioma que queremos modificar (en nuestro caso, el Español). Una vez en la vista formulario, debemos modificar los siguientes campos con estos valores:
Formato separador: [3,0] (en vez de [])
Separador de miles: . (en vez de un valor vacío)
Ya que estamos en esta vista, podemos asegurarnos de que no se nos presenta uno de los bugs más molestos que se dieron en las primeras revisiones de la versión 6.0, que consistía en que las horas estaban con un formato ‘%t’ en vez de con un formato -por ejemplo- ‘%H:%M:%S’, que provocaba que los campos datetime fallasen al no poder cargar correctamente sus valores por defecto.
