Estado Edición de fechas


([N4] ns) #1

Buenas,

la edición de las fechas necesita mejorarse, que son ya muchas versiones y esto sigue igual. El trabajo con estos campos es lentísimo y cero por ciento intuitivo.

Unos ejemplos:

-Intenta escribir en un campo fecha desde teclado la siguiente fecha 31/12/2014. Y ahora mira el campo y dime que fecha realmente ha quedado en el campo.
-Modifica una fecha que ya tenía valor 05/02/2014 (desde teclado) por este otro valor 31/03/2014. ¿Lo has conseguido a la primera?
-Sería de agradecer que se pudiese indicar el año con 2 dígitos, como se puede hacer en la mayoria de programas.

Saludos,
santiago.


([N3] pacosatu) #2

Hola Santiago.

Una de 2, o nadie utiliza este control o a nadie le molesta este comportamiento y tú eres el único (yo me añado a partir de ahora) que considera que esto es una aberración.

¿Cómo se puede limitar la entrada de un dato (el día) antes de determinar el dato que lo limita (el mes)? Para los americanos no hay problema que son los únicos que meten el mes antes del día, pero para los europeos y latinoamericanos es un engorro.

Lo más grave de este comportamiento es que provocará errores de entrada de datos indetectables, sobre todo para usuarios que teclean a más de 200 pulsaciones por minuto y conozco muchos.

Mientras tanto tocará editar la fecha con un Campo de tipo Alfa (con máscara dd/MM/yyyy o dd/MM/yy) y hacer la conversión a formato Fecha cuando se guarda el registro.

Saludos
Paco Satué


([N3] asesoria) #3

Efectivamente los errores que se producen son muchísimos.
+1


([N4] mamestre) #4

Para nosotros ha sido una gran decepción ver que este problema no viene solucionado en la 7.15.
Tampoco entendíamos que un problema tan serio como este tuviese tan poca repercusión en el foro.
La solución de campo tipo alfa… no es muy “Life is Soft” que digamos.

Toca rehacer el control.


([N4] velavisual) #5

Me apoyo en el comentario de Paco Satué

Para los americanos no hay problema que son los únicos que meten el mes antes del día, pero para los europeos y latinoamericanos es un engorro.

Este comportamiento en las fechas y que para nosotros es una incidencia son provocadas por las propias librerías de QT. Creo que está reportado este comportamiento a QT.


([N4] jordimas) #6

Joder, menos mal! creía que era un bicho raro! No es normal que el control edición fecha en una plataforma de software empresarial tenga este fallo desde hace ya no se cuantos años.

¿Sería normal que si en un campo numérico dónde se guarda un importe y se introducen 500 euros, el campo automáticamente guardara 498 euros? ¿No verdad? Pues eso es lo que pasa con el control edición fecha.

Nosotros llevamos pidiéndolo al soporte oficial desde hace unos 2 años, la respuesta es siempre la misma, esperan a que QT lo solucione.


([N4] José A. Martínez) #7

Puff… aterrorizado me acabo de quedar…y el inocente de mi que pensaba que el control edit de fecha solo tenia problemas de agilidad. Ahora veo que también tiene problemas de fiabilidad… Genial…


([N3] Juanjo) #8

Opino que la solución de Paco, debería hacerla Velneo internamente de modo que resulte transparente para nosotros. En principio creo que a ellos les afecta únicamente en una zona: el control de fecha.
Este control lo pueden editar como prefieran y devolver/filtrar el valor final a fecha.
El día que a los chicos de QT les de por arreglarlo (ya como si tardan 15 años), quitan de 1 sola zona el filtrado y listo. Sigue siendo transparente para nosotros y no hay que tocar nada.

Para nosotros es una paliza editar y controlar cada campo de fecha en otro modo, pero lo hacemos por nuestros clientes (y porque tienen nuestro telefono que hecha humo, o los vemos en la calle, …).

Velneo lo debería hacer por sus clientes. Yo a los míos no les puedo hablar de QT, porque al final de la explicación me dirían cualquier perla. :wink:

Hecho de menos el antiguo sistema de votaciones. Estaba a la vista y funcionaba a la perfección (en cuanto una idea alcanzaba cotas de mucho “ruido”, se anunciaba su aparición en la próxima versión, aunque fuese en Beta como vClient Android).

Ahora está escondidita, te tienes que identificar …, se apartó muy rápido el otro sistema.

Un saludo a todos,
Juanjo Gutiérrez.


([N3] synetic) #9

Respecto a mostrar el año con dos dígitos es posible hacerlo cambiando la configuración regional de la máquina.

Y un +1 a la revisión del control. En software empresarial los controles tipo fecha son fundamentales y su funcionamiento debería revisarse.


([N1] francisco) #10

Me uno a las opiniones dadas.


([N2] isaacpda) #11

Buenas tardes,
me uno al tema de edición de fecha, mi problema formateo el campo por ejemplo 2014-02-16 y en la bbdd me lo graba 16/02/2014 por lo tanto error. Espero que se solucione pronto.

Saludos
Isaac Díaz


([N1] alamillos) #12

Yo también me uno a esta petición, y prefiero no comentar sobre este asunto…


([N3] krear) #13

Santiago,

Acabo de probar lo que indicas y flipo!!! sobre todo con la segunda prueba, dado que mis clientes están acostumbrados a trabajar desde Velazquez y a la hora de introducir fechas no utilizan el primer ejemplo.

Y ahora empiezo a entender porqué en algunos casos mis clientes me comentaban que algunas fechas habían cambiado a fechas ridículas.

En su momento pensamos que es posible y aceptable que el usuario se equivocó al teclear la fecha, dado que si está introduciendo 100 reservas diarias en alguna se puede equivocar. Pero ahora la cosa cambia, quizás si han tecleado bien pero ocurre lo que comentas y el usuario no se fija en aparezca esta fecha tan ridícula.

+1 a comentarios y +1 a esperar a una próxima actualización.


([N1] jesfry) #14

Saludos.
Pues me ha parecido increíble todo esto, tantos años y aun con el problema. En la ultima versión del vERP sucede el mismo error. Esto indica que no han dado solución algo que en mi humilde opinión toda aplicación lleva y es el campo de la fecha.

Lo más curioso del caso es que inocentemente pedí a soporte la validación del tema y ellos allí sabiendo ya de la problemática me respondieron como si se tratase de algo que ya hay solución.

O estoy en lugar equivocado, o falta de seriedad de soporte no responderme con sinceridad.


([N2] Esfero) #15

+1


([N2] Mgalvezh) #16

Acabo de probar lo que pone en este post sobre las fechas y no se me produce el problema, alguien puede exponer cual es ? gracias.


([N1] vgegeo) #17

Es un error que corrigieron “en parte” en anteriores versiones.

Digo “en parte”, porque si utilizas la instruccion PEDIR DATO y el dato que solicitas es fecha, en el control FECHA que te ofrece dicha instruccion continúa el problema explicado en este post.

Saludos


([N1] vgegeo) #18

Cuando informé a Velneo dieron de alta la incidencia VELNEO-4307.
Yo informe en versión 7.18
En versión 7.19 no está resuelta
En version 20 tampoco aparece en el Listado de cambios de Velneo 20listado de cambio

La solución a esto es no utilizar la instrucción PEDIR DATO, y crear lo siguiente:
Crear formulario sin origen para editar una variable local fecha.
En el proceso que utilizabamos PEDIR DATO:
-Sustituir esta instrucción por:
-Crear manejador de objeto (el formulario que hemos creado)
-Disparar objeto
-Leer variable local del objeto

Y aqui ya tienes el valor para guardar en tu variable fecha que tengas en el proceso.

Ahi es nada, no funciona un control fecha, y hay que sustituir una instruccion por un formulario y 4 instrucciones.

Muy Life
Muy Soft

Más saludos :wink: