Para comenzar hablaremos de, GNU Solidario en CISL 2011. Conferencia Internacional del Software Libre. La Conferencia tendrá lugar en Buenos Aires los días 8 y 9 de Septiembre.
Luis Falcon, de GNU Solidario, presentará su charla sobre “GNU Health (AKA Medical)”: El Sistema Libre de Gestión Hospitalaria y de Información de Salud” el día viernes 9 de Septiembre a las 10 hs en el Aula 3.
Una utilidad que tiene el cliente GTK y no el web es la de poder imprimir los listados que ves en pantalla.
Por ejemplo, tienes una vista de búsqueda, ajustas los parámetros a como quieres, le das a imprimir y sale tal cual, sin necesidad de crear el informe 1 a 1 para cada uno de los objetos.
Esto es un gran atraso del cliente web respecto al de escritorio que quizás podamos cambiar.
Una vez dentro, le damos a Sign, que sólo nos pide una cuenta de correo y un nombre de usuario y votamos (botón vote, debajo de los votos, a la izquierda arriba)
Tenemos un número limitado de votos, que podemos volver a utilizar una vez que una idea es desechada o bien se realiza.
También podemos especificar cuantos votos asignarle a la idea.
Gracias.
Para más información sobre OpenERP visita nuestra web haciendo un clicaquí.
A lo largo del artículo veremos que hay que hacer para poder trabajr con informes de Aeroo de listado de clientes.
Pero antes me guustaria recordar que, en la web oficial tenéis un foro dedicado a los productos del creador, donde podéis realizar consultas y leer las ya expuestas, aunque la existente actualmente no es para tirar cohetes.
En contra, quizás la instalación que es un poco más costosa, y el hecho de necesitar tener instalado OpenOffice (también lo puedes tener aunque no tengas escritorio instalado, lo que viene a llamarse modo headless) para la conversión de los informes a formato .PDF (de forma nativa, genera .odt o bien .ods, formatos opendocument)
Permite el acceso a funciones de python, con acceso a todos los objetos de openerp, mediante los parser.
Bueno, si queréis más info podéis visitar la web del creador: Alistek
De regalo, adjunto una plantilla .odt que imprime los partners seleccionados en formato apaisado a4, donde podréis ver algunos ejemplos de directivas, como poner en un informe la fecha actual, recorrer una serie de objetos, numerar páginas, . . .
Para su uso, primero instalar aeroo + aeroolib, configurar un informe utilizando el .odt proporcionado como plantilla, crear un botón para llamar a la acción y probar.
p.d. Edito para añadir un .pdf generado con esta plantilla para mostrar como queda
Un saludo.
Por último, si quiere obtener más información, sobre listado de clientes puede visitar nuestra página web haciendo clic aquí. o el siguiente enlace que le adjuntamos:https://www.domatix.com
Y es que el problema en el cliente web y su lentitud parece residir en la gran carga de trabajo (peticiones SQL) que son necesarias realizar para mostrar un tablero o dashboard, con datos en tiempo real.
Esos cálculos para mostrar estadísticas, gráficos, etc., son una gran carga de trabajo.
Ésto, y el hecho de que cada vez que cambiamos de aplicación se recargue el dashboard, hace que la navegación no sea fluida, y que los clientes se desesperen y vean un producto que no es el deseado.
Para que os hagáis una idea, algunos clientes, han cambiado de máquina servidor, y comentan que han experimentado un gran cambio (pero aún notan la lentitud) con procesadores i7, 8 GB de Ram, sata3, etc., frente a celeron, atom y similares, en los que trabajar suponía tener una gran paciencia.
Una solución propuesta por Borja o rvalyi, es que los tableros sean precalculados, de manera que se puedan generar mientras trabajamos, o bien por la noche si tenemos demasiados datos. El caso es que no se calculen al vuelo, lo que supone lentitud.
Otra solución (módulos de rvalyi), ya posible, es la desactivación de los tableros al cambiar de aplicación, de manera que sea el usuario el que tenga que ejecutarlos manualmente al seleccionar la opción del menú correspondiente.
Los módulos:
Esperemos que la refactorización de la versión 6.1 del cliente nos mejore éste aspecto (aunque parece que las mejoras no apuntan a ello).
Todos éstos problemas no los tenemos con el cliente GTK, más rápido, pero claro, no es tan visual, ni ofrece tantas opciones como la conectividad, mover citas en los calendarios arrastrándolas, . . .
Seguiremos informando.
Para más información sobre OpenERP visita nuestra web haciendo un clicaquí.
Ya estamos de vuelta de las Jornadas Nacionales de OpenERP de este año, celebradas en Lugo tal y como anunciábamos en nuestra entrada anterior. Antes que nada, reiterar nuestras felicitaciones a Pexego dado que salió todo perfecto y ejercieron de excelentes anfitriones.
Para más información sobre OpenERP visita nuestra web haciendo un clicaquí.
Durante los días 26, 27 y 28 de Mayo se van a celebrar las ya tradicionales Jornadas Nacionales de OpenERP con Ting!. Este año le corresponde a Pexego el honor de organizarlas, y nos han preparado un programa muy entretenido que disfrutaremos en su ciudad, Lugo.
Para más información sobre OpenERP visita nuestra web haciendo un clicaquí.
Hemosempezado a trabajaren la ampliación de MEDICAL en apoyo deTryton ERP.TrytonesunERPconunagranfilosofíadel SoftwareLibre,no sólo por tener el códigofuentelibre si no también para tener una política de NO LOCK-IN. Esto es lo que vamos a conseguir:
MEDICAL y Tryton
– Libertad deelección:ahorael usuariotendrátotal libertaden el Sistema Operativo,Base de DatosoERP.Elusuariopodráelegir entreOpenERPoTryton.
– Upgrades Garantizados: debebasarseenuna arquitectura quepermitaal usuario actualizarsuinfraestructura.Los usuariosylos centros de saluddebenpodercontar con las herramientasde actualizacióny documentaciónparaactualizar el sistema operativo,base de datosy ERPsincostosi así lo desean.Es por eso que lo vemosenGNU/Linux,PostgreSQLyTryton.Esteesquemagarantizaque el usuariofinal tenga laversiónmásactualizada de MEDICAL.
– Independencia del proveedor: Nosotros,comocomunidad,para elfuturo deMEDICAL (o de cualquier otra solución de software libre)no podemos dependerdeunúnico proveedor o de un grupodeproveedores. Éste,no perteneceaThymbra. Además, esparte deunaorganizaciónsin finesde lucro:GNUSolidario,queno se puedecomprary no puede caer en manos deespeculadores.
– Volver a las raíces: Tenemosquevolveralosorígenesdelsoftware libre.Como ya hedicho,nose tratasólode “código abierto“,sino también de comunidady ética.
Por esta razón, ahoracreo quetenemosel escenarioperfecto para lalibertaddeelección,la independenciadel proveedor, políticas de NO LOCK IN, comunidady evolución.Estos factores garantizanlacontinuidad de MEDICAL para la versión actualypara todas las próximas.
De igual manera, vamos a seguir desarrollando MEDICAL para que tenga la misma funcionalidad en todos los ámbitos (OpenERP,Tryton,GNU/Linux,FreeBSD…).
Hoy es un gran día para MEDICAL y para el Software Libre !
Una comunicación clara y directa entre los clientes y la agencia es un factor clave de éxito como prueba de profesionalidad.
Actualmente se piensa que, al ser el cliente el que paga, esto le hace dueño de poder exigir como quiere que se hagan las cosas. Cuando se presenta ante nosotros, nos muestra su necesidad y qué es lo que está buscando. En ese momento, el cliente nos está buscando por algo. No siempre sabe cual es la mejor solución a su necesidad. Es por esto, que nosotros como profesionales, tenemos que guiarlo, aconsejarle, planteando nuestra reflexión y enfoque profesional en cuanto a sus ideas en el caso de opinar diferente.
Desde un primer momento se debe de tener claro el rol de cada uno. El cliente es el que pide una solución a una demanda y el proveedor es quién la resuelve. Sin embargo, muchas veces esta “división de competencias” tiende a pisarse por parte de ambas partes. No sólo el cliente comienza a pedir cambios o mostrar la ruta que quiere tomar, sino que nosotros como proveedores cedemos sin pensar si es la mejor decisión, sólo lo vemos como “lo está diciendo quien nos paga, por lo tanto hay que hacerlo”, grave error.
Debemos tomarnos un minuto, analizar lo que se nos está pidiendo, ver otras opciones y saber si esta es la solución idónea. El cliente nos contrata para que le ayudemos como profesionales en el tema, y seguro que valorará más si investigamos las consecuencias de lo que nos está pidiendo y le recomendamos no hacerlo, dando razones justas y mostrando los posibles malos resultados. No se trata de sólo decir no, es enseñarle alternativas a lo que está buscando. Proponiendo opciones más adaptadas a sus necesidades y sobre todo soluciones diseñadas para lograr los objetivos planteados. Ahí verdaderamente damos un servicio íntegro y no nos convertirnos simplemente en un departamento de producción.
Tenemos que enseñar a nuestros clientes como pueden sacar un mayor partido a nuestros servicios, aconsejándoles que miren más allá del proyecto que piden. De la misma manera, tenemos convencerles de que se dejen asesorar por nuestra amplia experiencia y no centrarse únicamente en resultados a muy corto plazo. Y finalmente, mostrarles cómo enmarcar las acciones en una estrategia a medio y largo plazo.
Como profesionales debemos generar confianza para que los clientes dejen el proyecto en nuestras manos. Esto se logra no sólo diciéndoles sí a todo, sino demostrándoles cómo. Los expertos, nosotros nos consideramos como tal, escuchamos, haciendo caso a sus ideas y tomando la mejor decisión, para convertirnos en un valor añadido para su empresa.
Es indiscutible, que debemos cuidar de nuestros clientes por encima de todo, y que sean el centro de toda la estrategia. Pero no debemos olvidar que somos nosotros quienes tenemos que guiarlos, mostrarles el camino y llegar a soluciones que terminen en buenos resultados.
Cuando admitimos todo lo que el cliente nos pide, y le damos la razón, inmediata, no sólo demuestra que tenemos una visión limitada de su negocio, si no que estamos tomando la vía fácil, donde no aplicamos ningún esfuerzo y no logramos entender lo que realmente necesita. Es aquí donde debemos pararnos, y pensar cuál es el verdadero servicio que le queremos brindar a nuestro cliente. Si queremos ser profesionales, debemos analizar varios factores, por ejemplo, si lo que nos pide está estrechamente ligado con la estrategia que estamos desarrollando, si estamos optimizando la inversión o si realmente apostamos por una acción necesaria.
Es imprescindible tener una comunicación clara y directa con nuestros clientes, donde estemos abiertos a escucharle y a que nos escuchen, donde verdaderamente haya un trabajo de investigación y análisis de cada propuesta o decisión.
Hace un par de días, un programador compartió un problema que tenía en el chat. En el caso de tener un campo al que se le quiere añadir un sufijo que pero al mismo tiempo tiene otro campo, y ambos campos están definidos como traducibles… ¿como puedes hacer para combinar los dos campos en todos los idiomas disponibles?
Funcionamiento de los campos multi idioma
En primer lugar, debemos saber que cuando llamamos a uno de los métodos del orm en el context, 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’.
De esta manera, 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, automáticamente realizará la operación sobre el primer idioma (por defecto en_US).
Asimismo, 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 de igual manera, 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’.
# obtengo el idioma del context previous_lang = context.get(‘lang’)
# recorro todos los idiomas lang_ids = lang_obj.search(cr, uid,[]) for lang in lang_obj.browse(cr,uid,lang_ids):
# guardo el idioma en el context context[‘lang’]= lang.code
# obtengo en producto, pasando el nuevo context para que me devuelva en nombre en el idioma pasado for product in product_obj.browse(cr,uid,ids, context): # escribo el producto con los cambios, pasando el nuevo context para que escriba el nombre en el idioma pasado product_obj.write(cr, uid, product.id,{‘name’:product.name+‘-‘+product.name}, context)
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:
