Retomamos a la vuelta de vacaciones, tal y como ya anticipabamos en los primeros días del mes de Agosto, la idea de adentrarnos en el conocimiento de las distintas plantillas de Velneo. Nuestro objetivo es un primer acercamiento que nos de, tanto a vosotros como a mi, una pequeña idea de qué nos pueden ofrecer.

Velneo mantiene actualmente un total de 18 plantillas profesionales, de las cuales no todas responden a la idea que podemos tener de aplicacion de gestión, puesto que algunas son herramientas adicionales (pluggins o utilidades) que complementan nuestros desarrollos. Podría ser el caso de la plantilla v2Excel que nos permite hacer uso de las hojas de calculo en nuestros mapas de una forma sencilla. O el caso de vMail o vFtp, cuyos nombres nos indican de forma clara el motivo de su uso.

En este caso, nuestro punto de mira se pone en la vTpv, que es el mapa que nos proporciona un interfaz de trabajo con lo que habitualmente llamamos como Terminal Punto de Venta. Como cualquiera de vosotros, dispongo de algunos desarrollos activos a la fecha de hoy. En mi caso todos están hechos en Delphi y responden a las típicas aplicaciónes de gestión. Delphí es la herramienta que he usado de forma continuada durante bastantes años, con las versiones 2, 5 y 7, principalmente. Por esa razón, pensé que sería interesante estudiar el planteamiento desde el que se aborda la aplicación de Terminal Punto de Venta basada en la plantilla vTpv. Era un tipo de desarrollo al que ya estaba acostumbrado y que yo mismo había implementado soluciones similares de diversas formas, según las necesidades de la empresa.

Se me ocurrió la idea, buena o mala ya depende del prisma con el que se mire, de ofrecer de forma desinteresada la implantación de un desarrollo basado en la vTpv a un pequeño comercio, lo cual me iba a permitir extrapolar algunas conclusiones a comerciós o empresas de mayor tamaño. No se como lo veis vosotros… pero no me apetecía enfrascarme en un desarrollo dificil sin conocer realmente la herramienta. Evitar hacer grandes cambios, solo los mínimos (ninguno era casi imposible). Y ver entre otras cosas, si el usuario se encuentra comodo con la aplicación, lo que a veces denominamos usabilidad. Además, hacer la implantación de un desarrollo en una empresa trae habitualmente la necesidad de hacer uso del motor de la base de datos, y para evaluar la plantilla realmente no es necesario, salvo que quieras estudiar su comportamiento en un entorno de red, que no era el caso.

El comercio era una tienda del sector de la moda, en la que se podían ver algunos vestidos de fiesta de un diseñador de la provincia. Un comercio pequeño, con un único terminal de punto de venta (TPV) y un montón de chicas guapas (modelos) que acudían de cuando en cuando a probarse los diseños… (jejeje una buena excusa para verificar el buen funcionamiento del sistema en las tardes en que se producían las reuniones)

Hago este comentario porque en el pequeño video que va a acompañar esta entrada, en lugar de aparecer imagenes que hagan referencia a vestidos o trajes, vereis referencias a los productos habituales de un restaurante. El motivo de este cambio es simplemente por dar una apariencia más real a la aplicación, conforme a lo que entendemos generalmente por TPV. En el foro de Velneo un compañero facilitó imagenes de productos relacionados con la restauración y ciertamente se consigue que el interfaz sea un poco mas atractivo. Pero es que además, y por deciros algo, estuve tentado de eliminar toda la parte de los casilleros que mostraba el interfaz (casilleros de familias de primer nivel, de segundo nivel y de articulos) ya que al incorporar la lectura del codigo de barras dejaban de ser imprescindibles y podrían haber sido eliminados. De hecho, en dicho comercio no son utilizados ni disponen de imagenes. El usuario introduce el código de barras de la etiqueta del vestido y poco mas.

Si os parece podemos empezar a comentar que tal fue la experiencia. Intentaré ser lo mas objetivo posible.

¿La puesta en marcha…?

Aproximadamente tardé un par de semanas, mas o menos, (quizás algunos días más) en entregar el proyecto y ponerlo en marcha. Esta cuenta de días es imprecisa porque forman parte de los proyectos (queramos o no) una serie de circunstancias ajenas a la misma aplicación, como pueda ser el que te puedas encontrar con una impresora de tickets de segunda mano, bastante antigua, de la que no tienes documentación. Buscar entonces en internet los codigos de control que producen la apertura del cajon puede ser tan complicado como encontrar los drivers para su instalación, si es que la misma está descatalogada. Muchos compañeros que leen estas lineas saben de lo que hablo y seguro que sonrien.

Por otra parte, lo único que se me pedía es que la adición de productos en el ticket abierto, se debía producir leyendo desde un codigo de barras o bien introduciendo éste de forma manual por el usuario. Esto alteraba el interfaz del tpv que estaba mas orientado a la pulsación del articulo desde un casillero, bien desde el ratón, bien desde una pantalla táctil. Así que parte de ese tiempo lo dediqué también a conocer como se producía la inserción de los mismos en la linea de detalle del tiquet, una vez pulsado el casillero. En el video se muestra con cierto detalle que cambios hice.

Hay un pequeño olvido. (Pensé que no valía la pena volver a editar el video y que en esta entrada lo podríamos ver) En la ventana de variables del proyecto se muestran dos nuevas variables añadidas. Una lógicamente para capturar el valor de la referencia del artículo. La otra booleana, según narraba para discriminar cuando operabamos con la casilla de edicion de cantitad y cuando con la casilla de código. Sin embargo no dije que esto afectaba al teclado que mostaba el Tpv. Los procedimientos asignados a la pulsación de los distintos botones del teclado deberían estar dentro de la carpeta de objetos modificados. Un olvido.

Elijamos una de las teclas al azar. Por ejemplo la del numero 8. Esta es la asignación del proceso que se ha hecho a la pulsación de la misma.

Y esta imagen se corresponde al proceso:

Aquí se puede ver que dependiendo del valor de la variable CURSO-VTICK-GE-CURSO-SELECCION (0 ó 1) vamos a concatenar el valor que se ha digitado a la casilla de edición de cantidad o a la casilla de referencia de artículo. La flecha verde que acompaña dichas casillas advierte al usuario de cual es la que se encuentra activa.

Para cambiar la selección basta pulsar sobre la etiqueta UNIDADES o sobre ARTICULO, lo cual disparaba respectivamente un proceso que simplemente modificaba el valor de la variable a 0 ó a 1, segun el origen de la pulsación. Ha faltado quizás cambiar la apariencia de la etiqueta para que se asemejara mas a un boton, pero os comento que no ha sido necesario porque el usuario no tuvo el mas mínimo problema. Estos truquillos, originados por las caracteristicas propias de este tipo de menus, que no permite un control efectivo del foco, han sido subsanados en la próxima versión de Velneo con la unificación de los menús, lo cual me alegra enormemente. En una de las entradas anteriores, la que hacía referencia al juego del Tres en Raya hablabamos con mayor detalle de esta problematica.

Mi valoración de la plantila vTpv, que lógicamente incluye la vGestion, si tuviera que puntuarla tras la puesta en marcha del proyecto, podría estar en un notable, teniendo en cuenta siempre que NO estoy valorandola desde el punto de vista cliente/servidor.

Esa es mi opinión y entiendo que cada uno es libre de tomar los criterios que crea conveniente en esta valoración. Los mios han sido multiples:

* El usuario se adaptó desde el primer día a la aplicación sin excesiva dificultad. Hicieron falta tan solo unas mañanas en las que se abordaron los detalles básicos de configuración y la mecanica de trabajo. El hecho de que todas las ventanas muestren una operatoria similar facilita enormemente que el usuario se adapte: una vez sabe dar de alta, modificar, eliminar o buscar un registro, que son las operaciones mas habituales, es capaz de operar en cualquiera de los módulos, ya sea de ventas, compras, almacen o configuración.

Además, hay que reconocer que el manual que se entrega con la plantilla es un detalle a tener en cuenta, pues supone algo que en la mayoría de las aplicaciónes hechas a medida se deja para el final y la mayor de las veces queda por finalizar por falta de tiempo o pereza. Ese es el mundo real…

* Otro criterio que me hace puntuar positivamente la plantilla es que se nota que el analisis de la misma, se ha hecho de forma cuidada. Es algo que pude observar al visualizar tanto la documentación como el seminario que se impartió por Velneo sobre ésta. Que se ha hecho de forma “cuidada” se podría ver simplemente al ver como se relacionan las tablas mas corrientes de este tipo de desarrollos: Disponemos en el modulo de ventas de presupuestos, pedidos, albaranes, facturas y tickets, estos últimos unificando en una única tabla de movimientos de almacen, los historicos correspondientes. El módulo de compras sigue un esquema similar. Eso simplifica por ejemplo, que de ser necesario disponer de una aplicación que gestione múltiples almacenes (que suele ser habitual) tan solo necesitemos modificar la tabla de movimientos con la inclusión del nuevo dato o relación hacia el almacén. Todos estos detalles se comentan de forma intensiva en los distintos seminarios.

Quizás el mismo hecho de necesitar una plantilla lo suficientemente general para que pueda ser usada por multiples negocios haya condicionado la necesidad de meditar las decisiones de diseño de la misma.

* Y finalmente, se suma a esa valoración positiva la posibilidad de integrar nuevas plantillas que hagan escalable la aplicación de forma sencilla. En el video no se muestra ésto, pero podemos comentarlo en otra entrada posterior. Disponer de un modulo de contabilidad que puede ser activado es importante porque a menudo suele ser requerido. Realmente no es imprescindible, ni lo requieren todos los posibles clientes, entre ellos negocios que funcionan en España bajo la regulación de los Módulos y que en muchos casos se eximen de llevar una Contabilidad. Usando la terminologia de Velneo, la metamorfosis al vuelo toma un papel determinante en el hecho mismo de integrar desde el almacen de objetos cualquier otro mapa que extiendan la funcionalidad del desarrollo.

Dentro de este punto, que he resumido como desarrollo escalable, podríamos considerar la potencia que nos aporta en la versión Enterprise la ejecución funciones remotas, a la cual dedicaremos un poco mas adelante una o mas entradas. Os pido un poco de paciencia. No quiere decir esto que no podamos obtener resultados similares si varias plantillas se integran en un solo proyecto o mapa, sino que se adquiere mayor flexibilidad y distribución, asi como tambien mayor optimización del mantenimiento.

¿Y lo malo no lo vas a decir?

Esto no es un folleto publicitario… =:-O ¡Dios me libre!

Pues claro que tiene carencias y si pones a cualquier usuario frente a dos aplicaciones, una hecha con Velneo con la versión V6 y otra con cualquier entorno de desarrollo actual, la apariencia misma de la aplicación pesa mucho y el usuario casi con seguridad va a querer esta última, aunque sea una castaña. Así que si tu aplicación funciona vas a tener un pequeño esfuerzo adicional en valorar otros aspectos que puedan inducir al usuario a aceptarla así. Pero todo esto ya lo comentamos en entradas anteriores. No añado nada que no haya dicho. ¡Ojo!. Hablamos de la V6… Porque la V7 es otro cantar…

Respecto a la vTpv/vGestión yo quizás las hubiera diseñado teniendo en cuanta la necesidad de ser multiempresa, con la opción de trabajar con una sola o varias. Pero esto tambien es opinable y entiendo que forma parte de esa necesidad de tener una plantilla mas general.

Hay algunos detalles que hubieran sido agradecidos ya que se hace necesarios de forma habitual. Quizás que se hubiera considerado la generación de remesas bancarias segun las normas que dicta las Cuadernos del Consejo superior bancario. Operaciones como la negociacion de efectos, los recibos descontados o el anticipo de creditos son habituales y se integran en las apliciones de gestión a través de las distintas Normas.

Tampoco se ha tenido en cuenta disponer de algun selector de la forma de pago en el interfaz del tpv para considerar operaciones a credito, sin tener que acudir al mismo ticket a modificarlo.

O si me apuras, disponer de algun pluggin, herramienta adicional o plantilla que permitiera generar etiquetas de codigos de barras desde la misma aplicación. Se podría quizas haber hecho desde los informes diseñando las etiquetas y disponiendo de unas tablas para insertar los datos.

Si vas raspando… seguro que encontraras muchos mas detalles.

En conclusión y finalizando… mi valoración es positiva en lineas generales.

He preparado un mapa vacío que incluye los cambios que comento en la entrada y que se ven en el video. Intentaremos en la medida de lo posible apoyarnos en estas ayudas visuales para complementar las entradas tanto de Delphi como de Velneo.

* Descarga del mapa de cambios.

* Ver video.

Espero que os guste y que pueda servir de alguna ayuda todos estos comentarios y reflexiones.

Es importante intentar tener un criterio propio, independientemente de hacia donde pueda soplar el viento. Si os equivocais al menos os equivocareis vosotros…

Contador gratuito