Un amigo
Mi amigo, Emilio Márquez, acaba de dar esta noticia luchando con el linfoma. Emilio es amigo mío desde hace ya más de 20 años... en su época nos conectábamos a las BBS, o bien, nos pasábamos juegos (increíble The Day of the Tentacle), todo ello mientras estábamos en el instituto, entre rezo y "Salve Don Bosco Santo" al... Ha habido época en las que hemos mantenido el contacto, y otras en las que menos. Pero eso no deja de ser una anécdota, porque lo considero un amigo.
Emilio, para cualquier cosa que necesites, ya sabes dónde estoy.
Un abrazo.
AbanQ: Añadiendo una nueva columna de ordenación en el FLDataTable
El trabajo con sistemas ERP, y especialmente con AbanQ siempre se basan en la navegación por listados de datos (o grids de datos). No estoy muy seguro de que realmente ese sea el sistema más usable o adecuado, pero al menos es muy popular.
En mi afán de tratar de hacer la herramienta aún más usable, echaba en falta una segunda columna de ordenación. Si mi empresa factura todo a través de AbanQ, el número de datos en esa rejilla es grande. Puede filtrarse utilizando el campo de filtro directo que AbanQ provee, pero ese campo de filtro también limita la ordenación de los datos filtrados que se presentan. Tener una segunda columna, como aparece en la imágen, puede ayudar aún más a localizar datos rápidamente.
Bien, veamos cómo hacerlo.
Como siempre, tocaremos un poquito de código de AbanQ... y de Qt 3.3.
AbanQ: Ampliando la funcionalidad de los optionslist
Una de las ayudas que tiene AbanQ a la hora de construir formularios que presentan registros asociados, es sin duda la posibilidad de definir OptionsList. Para una columna de base de datos, podemos definir un conjunto de posibles valores que se almacenarán en la misma, utilizando el tag optionslist dentro de la definición del campo, en el .mtd de la tabla correspondiente. AbanQ, automáticamente, creará un combobox en la vista (el formulario) para que el usuario sólo pueda escoger uno de esos valores.
Pero esta solución, aunque muy buena, no es óptima. Si la columna es un campo de tipo varchar (o string, como se le llama en AbanQ), el optionslist, guarda siempre en esa columna la cadena entera. Supongamos, por ejemplo, una columna "tipo_articulo" y un options list
<optionslist>Articulo prefabricado, Materia prima, Producto intermedio, Producto terminado</optionslist>
El detalle, es que esas cadenas se almacenan constantemente en la columna de la base de datos. Eso no es mayor problema si queremos indexar sobre esa columna, por ejemplo... Quizás es más interesante, el poder guardar en lugar de esos valores, otros, según la siguiente relación
<optionslist>Articulo prefabricado, Materia prima, Producto intermedio, Producto terminado</optionslist> <optionsvalues>1,2,3,4</optionsvalues>
De esta forma, cuando el usuario escoga en el combo box "Artículo prefabricado" en la columna de la base de datos, se guardará un 1.
Perdón a todos…
Perdonadme... Muchos meses de abandono del blog. Los motivos han sido personales y de toda índole. Algunos para bien, otros para mal. En cualquier caso, el blog ha sido el perjudicado.
Propósito de enmienda: Al menos una entrada semanal...
Saludos
Ahorrando prácticamente: Implantemos una centralita Asterisk (II)
Llegados a este punto ya tenemos configurado el entorno alrededor de Asterisk: Tenemos un ordenador, con las tarjetas digitalizadoras de voz instaladas, conectado a nuestra red (si Trixbox ha cogido sólo IP por existir en la red un servidor DHCP, será muy interesante que la IP de la centralita sea fija... salvo que queráis configurar adecuadamente los DNS de vuestro servidor de red, pero eso es otra historia), y tenemos configurado el driver Zaptel para que Asterisk pueda utilizar las tarjetas OpenVox.
A partir de este momento, podemos distinguir a grandes rasgos 3 grupos principales de elementos a configurar:
- La configuración del módulo encargado de utilizar las líneas analógicas (las de teléfono de toda la vida): Zapata
- Configuración general de Asterisk
- Dialplan (el conjunto de extensiones y reglas internas a nuestra centralita: nuestra instalación local)
Ahorrando prácticamente: Implantemos una centralita Asterisk
Voy a atreverme a publicar una serie de post con cómo implantar una centralita telefónica de bajo coste, y capaz de dar un servicio muy avanzado. Indicaros que no soy ningún experto en Asterisk, que es el software que vamos a utilizar, aunque he averiguado lo suficiente como para implantar mi propia centralita.
Os comento de dónde parto y a dónde quiero llegar. Dispongo de 4 líneas telefónicas analógicas (sí, de esas que tenéis en casa), que además están configuradas en salto (esto es, tengo 4 números de teléfonos asociados a estas 4 líneas. Llamando a uno de esos números obtengo una de las 4 líneas, y no tiene por qué haber una correspondencia unívoca. Así podría tener 4 llamadas distintas de 4 usuarios que han marcado el mismo número).
Quiero llegar a tener una centralita con operadora virtual (esa locución que se obtiene en algunos teléfonos: "Pulse 1 para..."), con buzones virtuales por cada extensión, y por supuesto libertad absoluta para configurar mis extensiones, grupos de extensiones...
A los que saben realmente de Asterisk: voy a montar algo muy sencillo y obvio. Pero, muy efectista y además práctico. Vamos a ello
Bug en AbanQ: Filtrado de campos double, int o uint desde FLTableDB
Creo haber descubierto un bug en AbanQ. La manera de reproducirlo es la siguiente:
Desde un FLTableDB, pinchamos en la opción Ver/Ocultar filtro. Escogemos ahora cualquier campo del tipo "double", "int" o "uint", modificamos la operación a Igual a (cualquier otra también vale para reproducirlo) e introducimos un valor. Al intentar ejecutar el filtro, si tenéis una base de datos PostgreSQL os dará un error, indicando que no se puede ejecutar la función "upper" sobre el campo.
El lugar donde se produce el bug en el código está situado en FLTableDB.cpp, en las líneas 1132 hasta 1137, dentro del método tdbFilterBuildWhere, y es fácil de ver: (código correspondiente al fuente del build 15245 disponible en la web de AbanQ)
case QVariant::UInt:
case QVariant::Int:
case QVariant::Double:
case QVariant::String:
case QVariant::StringList: {
fieldArg = "upper(" + fieldName + ")";
Si os fijáis se aplica la función de base de datos "upper" a todos los campos. Esta función sirve para poner en mayúsculas una cadena de texto (AbanQ la utiliza para garantizar la comparación de cadenas de caracteres independientemente de que el usuario la introduzca en mayúsculas o minúsculas: se compara siempre en mayúsculas). El error está en que PostgreSQL se queja cuando a una columna integer o double precision se le hace un upper.
Así no es posible aplicar un filtro a este tipo de campos. ¿Solución? Super sencilla. Cambiad ese código por este, y recompilad
case QVariant::String:
case QVariant::StringList: {
fieldArg = "upper(" + fieldName + ")";
case QVariant::UInt:
case QVariant::Int:
case QVariant::Double:
Así, el upper sólo se aplica a las cadenas.
Buenas prácticas en AbanQ: Usando vistas con PostgreSQL
Una de las características fundamentales de los sistemas ERP es el ofrecer información útil para el usuario. Generalmente, esa información útil surge de cruzar datos de diferentes orígenes (en nuestro caso, tablas de base de datos).
Vamos a poner un ejemplo: En AbanQ tenemos el formulario de artículos dentro del módulo de almacén. Quizás sería interesante añadir una opción para comprobar los movimientos de stocks, entendiendo por los mismos las entradas a almacén (albaranes dados de alta) y salidas (albaranes a clientes). Sería interesante visualizar en un TableDB el resultado de una query que agrupara ambas entradas. Claro, ocurre que para hacer esa query, es necesario utilizar una cláusula SQL, union. Así por ejemplo, podríamos desear tener una consulta tal como esta
select 'Entrada' as tipo, lp.referencia, lp.cantidad, ap.idalbaran from albaranesprov as ap inner join lineasalbaranesprov as lp on ap.idalbaran = lp.idalbaran union select 'Salida' as tipo, lc.referencia, lc.cantidad, ac.idalbaran from albaranescli as ac inner join lineasalbaranescli as lc on ac.idalbaran = lc.idalbaran
Tiempos de reducción de costes… ¡¡Software libre!!
Realmente, utilizar software libre, implica reducir costes (ojo, software libre no es igual a gratis, pero sí reduce costes). Ejemplo, teníamos necesidad de una nueva centralita de teléfonos. La actual, estaba desfasada y daba problemas. Pidiendo presupuestos a diferentes empresas, cualquier solución suponía un coste de mínimo 2.500 €. Toda una cifra en esta época.
Telefónica oferta propiamente el alquiler de una centralita y sus terminales, pagando un alquiler por teléfono y centralita mensual que es realmente interesante... Pero aun así, pensé en hacer una prueba antes. Utilizar Asterisk, una herramientaen software libre que permite implementar una centralita, utilizando además, protocolos libres (detalle este muy importante para futuras interoperabilidades) como SIP.
Así que manos a la obra, lo único que necesitaba era adquirir una tarjeta que recibiera las líneas de teléfono analógicas que tenemos contratadas. Las reinas indiscutibles en este sector son las Digium, básicamente porque son las tarjetas que desarrolla la empresa del creador y principal motor de Asterisk. Su problema, el precio. 180 euros para una prueba (en cualquier caso, mucho menos que 2.500 euros!!). Así, que adquirí las OpenVox, concretamente la A400P, que es un clon de la TDM410P (la de Digium)... Sí, OpenVox es una empresa china. Además, adquirí un módulo FXS para recibir llamadas.
Y manos a la obra, instalé TrixBox, una distribución Linux que viene ya preparada con todo el software para configurar una centralita... Me reconoció todo el hardware... y configuré.
En unas 6 horas, había configurado la centralita, con operadora virtual, grupos de capturas, múltiples extensiones, franjas horarias, buzones de voz... todo en un ordenador un tanto antiguo (un Pentium III con 256 megas de RAM).
O sea, que probando, he conseguido ahorrar 2.500 €... Y eso es lo que voy a hacer. Ahora dejaré las pruebas, y haré la implementación real de Asterisk en un ordenador algo más potente. Por supuesto, tuve FUD de algún que otro comercial ("ni te imaginas cuántas de esas asterisk he tenido que quitar..."). Asterisk es una solución tan buena como cualquier otra en este mundo. Hay empresas que se dedican a implementar este tipo de herramientas... y seguro que sale más barato. Por preguntar, y que os hagan una prueba, no perdéis nada.
FUD en Artes Gráficas
FUD son las siglas en inglés de Fear, Uncertainty and Doubt, es decir, "miedo, incertidumbre y duda". Son siglas muy utilizadas en el mundo de la informática y los sistemas de información, y aplicadas a grandes empresas, que mediante mensajes, declaraciones o campañas de publicidad pretenden sembrar la duda, el miedo y la incertidumbre en el consumidor para evitar que éste adquiera una nueva tecnología de un competidor.
Evidentemente, son prácticas, quizás no muy lícitas pero sí muy usadas en este mundo. Y digo, en este mundo, porque para sembrar MID (vamos a usar las mismas siglas pero en español, Miedo, Incertidumbre y Duda) debe utilizarse un factor importante: el desconocimiento del competidor sobre la nueva tecnología. Y es evidente que hablando tecnológicamente, no todo el mundo tiene porqué ser un experto.
Me sorprende ver, cómo esta práctica es usada intensivamente en el mercado de la maquinaria en Artes Gráficas. Lo normal de muchísimos comerciales (quisiera decir todos pero un principio de prudencia me lo impide) es utilizar expresiones tipo:
- "El servicio técnico de (TAL MARCA) es absolutamente pésimo. Bueno, yo conozco el caso de fulanito al que se le paró la máquina y estuvieron un mes sin atenderle!!!" (¿y cómo que no quebró?)
- "La teleasistencia no sirve para nada... eso de las comunicaciones remotas es un bulo" (¡¡Internet es un bulo!! ¿Qué hago escribiendo aquí?)
- "Esa máquina tiene una tecnología obsoleta, mira, tal sistema es de los años 70"... (en una máquina nueva... ¿y la vuestra que es la misma máquina de hace 10 años????)
- "Ufff, ¿la máquina de fulanito? Tuvieron que retirar dos en el cliente setanito"... (y las retiradas ni son tales y muchas veces son por otros motivos. Eso sí, nadie retira una máquina por mal funcionamiento, son siempre la de los demás...)
Podría seguir con un listado que tiende a infinito. La verdad, es que no me gusta ese estilo. A mí me gana el agente comercial que llega con la sinceridad y que utiliza argumentos como: "Mi máquina es verdad que flaquea con respecto a la de la competencia en tal aspecto, pero somos superiores en estos otros aspectos por tal, tal y tal" (me indica que el comercial ha estudiado a la competencia y tiene una opinión que dentro de la subjetividad es más real). "Sí, es cierto, la máquina que instalamos en tal cliente tuvimos que retirarla. Pero tiene ya una nueva" (indica que si su máquina me sale mal, me van a responder).
Quiero que establezcan con nosotros una relación de confianza y no de miedo hacia la competencia. Si la competencia hace lo mismo, la sensación final que queda es la de miedo. Iniciar una relación comercial con las bases de Miedo, Incertidumbre y Duda, al menos a mí, me sitúa enfrente de mi proveedor, y no al lado...
Categorías
- Artes Gráficas (26)
- ERP Open Source (20)
- General (26)
- Librerías Qt (24)
- Mundo empresarial (21)
- Programación (13)
- Uncategorized (1)
Mis blogs favoritos
Programación
Mi empresa
Entradas anteriores
- diciembre 2010 (1)
- octubre 2010 (1)
- abril 2010 (1)
- marzo 2010 (2)
- febrero 2010 (1)
- diciembre 2009 (5)
- noviembre 2009 (3)
- julio 2009 (1)
- junio 2009 (2)
- mayo 2009 (3)
- abril 2009 (4)
- marzo 2009 (12)
- febrero 2009 (2)
- enero 2009 (2)
- diciembre 2008 (6)
- noviembre 2008 (10)
- octubre 2008 (1)
- septiembre 2008 (6)
- agosto 2008 (5)
- julio 2008 (12)