No funcionan las actualizaciones


([N1] cfonseca) #1

Hola!

Tengo un problema con actualizaciones. Desde un formulario sin origen permito seleccionar un conjunto de registros de una rejilla (VENCIMIENTOS). Recorro esta rejilla para acumular unos datos utilizando Interfaz: Obtener la multi-selección y, una vez fuera de esa rejilla doy de alta un registro en otra tabla (COBROS). Para esto utilizo los comandos Crear nueva ficha en memoria y Alta de ficha. A continuación, y con Cargar lista, lanzo Modificar ficha seleccionada con formulario.
Hasta aquí todo correcto. A este formulario, en un evento On Init le cargo los datos que calculé en el Interfaz: Obtener la multi-selección anterior, y ejecuto una serie de comandos que hacen que el código del nuevo registro se genere correctamente de forma correlativa en el fichero.
Los campos tienen valores, y puedo añadir registros a sus históricos. De hecho, estos registros quedan perfectamente guardados y al entrar en modificación existen correctamente.
El problema está en que estos registros en los históricos no lanzan las actualizaciones sobre la cabecera, por lo que los valores numéricos de la cabecera se me quedan siempre a 0.
Si este formulario lo lanzo desde una rejilla de COBROS como formulario de alta, funciona todo perfectamente. El problema lo tengo cuando doy un alta y lo lanzo desde Modificar ficha seleccionada.
Ya os digo: funciona todo perfectamente excepto las actualizaciones.
¿Qué es lo que estoy haciendo mal?

Gracias de antemano.


([N1] wikan) #2

Simplemente creo que tienes la ficha bloqueada al hacer el cargar lista, es lo mismo que le pasa a un compañero hace poco con los refrescos.

Podrías crear un formulario de la ficha de cobro y una vez dentro buscar los vencimiento que deseas cobrar, cuando vayas a finalizar recorres la lista de vencimientos modificando su maestro de cobro.


([N1] cfonseca) #3

Antes de nada, gracias por la respuesta.
Esa solución no me vale. Necesito que el formulario de la ficha de cobro ya tenga el importe pre-cargado de los vencimientos que va a cargar, y a su vez que me permita poder pagar con uno o más ingresos, uno o más cheques, uno o más pagarés, … Lo curioso es que si me guarde todo sobre la propia ficha del cobro, y que también me guarde los históricos (ingresos, cheques, pagarés, …), pero que no me actualice los campos en le cobro que acumulan los importes de esos ingresos, cheques, pagarés.
Existe algún comando o alguna forma de que esto no suceda? En la teoría todo está correcto. El proceso se lanza desde un formulario sin origen, y en un punto del proceso en el que no estoy situado en ninguna tabla. Es un cargar lista simple. seleccionar ficha por posición simple y Modificar ficha seleccionada con formulario simple.
Todo está en pestañas excepto el formulario que me permite modificar el cobro, que es Modal.
No se. Un bloqueo sin sentido.


([N1] wikan) #4

El sentido del bloqueo lo tienes con el “Cargar lista” y seleccionar la ficha para modificación. En ese momento estás bloqueando el registro para su modificación y las actualizaciones que tiene que hacer el vServer no las puede hacer por el bloqueo.

Supongo que los vencimientos los marcarás cobrados en algún punto, incluso asignando ese cobro para tener una relación. De ahí que te comentará que directamente un formulario de la ficha de cobros podrías tener una búsqueda de los vencimientos, incluso anteriores a la fecha del registro de cobro.

De ahí en adelante puedes hacer lo mismo, obtener los vencimientos a cobrar, añadir formas de pago, etc.

En tu solución por ejemplo, si el usuario después de seleccionar los vencimiento cancela el registro de cobro, ya lo tienes dado de alta. De la otra manera hasta que no introduzca forma de pago no se genera el registro.


([N1] cfonseca) #5

Hola!

Gracias de nuevo.
El proceso, según las necesidades del cliente, es contrario a lo “lógico”. Necesita que le muestre los vencimientos, que pueda seleccionar los que quiere pagar, y que se genere un cobro sobre los vencimientos seleccionados. Una vez mostrada la pantalla del cobro con el importe a pagar, tiene que permitir elegir de que forma realiza el pago. Esto supone que el cobro tiene una serie de históticos (pagos al contado, transferencias, cheques, pagarés …).

Parece que la cosa es al revés de lo “normal”.

Intentaré hacer las actualizaciones de los importes por proceso. Supongo que así podré trampear esto. Sea como sea, si existe el comando Modificar ficha con formulario, lo normal es que eso abarcara todo lo que ese comando significa, ¿no?

Bueno. Intentaré y contaré.

Un millón de gracias nuevamente.


([N1] wikan) #6

Hombre el cliente no tiene por que saber el origen del formulario, por eso te digo. Si en vez de mostrar un formulario sin origen, abres un formulario de cobro y cargas los vencimientos anteriores a su fecha tienes el mismo efecto.

Una vez hecho eso, pasas al siguiente formulario ya con el cobro generado y sus vencimientos y actualizaciones realizadas, puedes asignarle formas de pago.

Eso si, si en algún momento el cliente cancela, tienes que eliminar la ficha de cobro y liberar los vencimientos.


([N1] cfonseca) #7

Gracias de nuevo.

Ya te digo. Eso sería lo lógico. De hecho, esa parte la tengo desarrollada perfectamente. Genero un cobro, presento los vencimientos pendientes de pagar, los cobro como quiero y todo va bien.
Este cliente trabaja con muchas cuentas bancarias, por lo que tengo que presentar los vencimientos que tiene pendientes al mismo tiempo que tengo que mostrar sus cuentas bancarias con sus respectivos saldos. Según la cuenta bancaria, generará un cobro, que puede ser de uno o más venvcimientos. Es decir, más o menos al revés de lo normal. Todos los datos de los que te hablo los muestro en un formulario sin origen, ya que tengo que tirar de muchas tablas. Además, en ese formulario también controlo pagos, cheques emitidos y recibidos, pagarés emitidos y recibidos, … Vamos, una locura de formulario, pero que le permite controlar la cobertura que tiene en todas sus cuentas.

La lógica dice que lo que hago está bien. Y lo que para mi es ilógico es que se bloquee una actualización cuando lo que estoy mostrando es el formulario de un registro en el que estoy posicionado. Y lo estoy en él y solamente en él. No hay nada más. Un Crear nueva ficha en memoria, Alta directa (aquí guardo el ID). A continuación un Cargar lista de este registro que acabo de dar de alta (con el ID que guardé en la instrucción anterior), Seleccionar ficha por posición (1) y Modificar ficha seleccionada con formulario. Simple. Sin más.
Y ya te digo … todo bien (campos, históricos, …) excepto las actualizaciones.

Sinceramente, me parece un sinsentido, pero bueno.

Ya me iré apañando.

Gracias de nuevo, y espero no darte la paliza.


([N1] wikan) #8

Pregunta a soporte, me parece que ese bloqueo viene por que haces un cargar lista desde el proceso y al hacerlo se bloquea la ficha ya que has abierto transacción, creo…

Quizás, depende del montaje. Después del alta, poner un añadir ficha a la salida y todo lo haces con una acción, a continuación podrías poner el formulario de cobro que te abriría la ficha reciente creada.


([N1] cfonseca) #9

Hola!

Listo. Con un proceso sin origen y una acción ya está resuelto.
En soporte me dicen que ya tienen aviso de esa incidencia. El problema me vendrá cuando la resuelvan, que en determinados sitios de la aplicación se me lanzará como una doble actualización, y tendré que depurar algo.

Paciencia.

Un saludo y un millón de gracias …


([N3] pacosatu) #10

Hola cfonseca.

No me ha quedado claro si soporte ha dicho que es un bug reconocido del motor de bases de datos de Velneo y por lo tanto disponible en Bugman.

Entiendo que lo que pasa es:

  • El registro principal está siendo editado con bloqueo duro con el comando de proceso “Modificar ficha seleccionada con formulario”, por lo tanto todo lo que hagamos (históricos, triggers, …) en el formulario se engloba en una ÚNICA TRANSACCIÓN.
  • Una vez que pulsamos Aceptar en el formulario todas las operaciones se confirman en la base de datos, pero parece que NO SE CONFIRMAN las Actualizaciones que se hayan realizado por los plurales en campos del registro principal. ¿Las actualizaciones no se enteran que están en una transacción abierta y cómo ven bloqueado el registro maestro no se ejecutan?

Si esto es así, creo que el tema es grave porque afecta a una funcionalidad clave en la integridad de la base de datos. Se debería aclarar si es conveniente o no usar el comando “Modificar ficha seleccionada con formulario” cuando esto implica el disparo de actualizaciones. Lo mismo para otros comandos de proceso que abren transacción, Modificar ficha seleccionada, Recorrer lista lectura/escritura, …

Saludos
Paco Satué


([N4] rpaton) #11

Hola:
Para una pantalla de registro de pedidos a proveedores doy de alta una ficha en PED_CM y luego con “Modificar ficha seleccionada con formulario” relleno los datos correspondientes (ver NUEVA-FICHA-PED-CM). Esta pantalla tiene una rejilla en la que indico los productos que estoy pidiendo al proveedor. Cuando añado cada línea se lanzan las actualizaciones al fichero de ARTICULOS sumando la cantidad al campo PEND_RECIBIR de la tabla ARTICULO y tengo indicado que se lancen también las actualizaciones a la Tabla PED_CM para acumular el importe total del pedido. Añado con NUEVA-FICHA-LIN-PED-CM.

 En la tabla PED_CM tengo un enlace al maestro PROVE para indicar el proveedor. Si relleno este campo la actualización para acumular el importe total del pedido NO SE LANZA. Sin embargo, si lo dejo en blanco SI SE LANZA. ¿Por qué?

 No tengo más actualizaciones ni restricciones que impliquen a la tabla PROVE. Es una simple tabla Cabecera-Detalle. A ver qué dice soporte.

 Saludos.

 Ricardo Patón

NUEVA-FICHA-PED-CM:
Crear nueva ficha en memoria ( Item, PED_CM@vTextilDat )
   Libre
Alta de ficha ( Item )
   Set ( ID_MASTER, #ID )

Cargar lista ( PED_CM@vTextilDat, ID, ID_MASTER, , , )
   Seleccionar ficha por posición ( 1 )
   Modificar ficha seleccionada con formulario ( PED_CM_EDITAR@vTextil, B_OK )
   If ( B_OK )
      Modificar ficha seleccionada
      Modificar campo ( DOC_NUM, fun:GET_NUM_DOC@vTextilDat.dat("PEDIDO COMPRA") )
      Interfaz: Ejecutar manejador de evento ( REFRESCAR, )
   Else
     Eliminar la ficha seleccionada
    


NUEVA-FICHA-LIN-PED-CM
Set ( ID_MASTER, #ID )
Crear nueva ficha en memoria ( Item, PED_CM_LINEAS@vTextilDat )
   Modificar campo ( PED_CM, ID_MASTER )
Alta de ficha ( Item )
   Set ( ID_LINEA, #ID )

Cargar lista ( PED_CM_LINEAS@vTextilDat, ID, ID_LINEA, , , )
   Seleccionar ficha por posición ( 1 )
   Modificar ficha seleccionada con formulario ( PED_LIN_CM_EDITAR@vTextil, BOK )
   If ( BOK )
      Libre
   Else
      Eliminar la ficha seleccionada
Libre
Interfaz: Recalcular ( REGISTROS )





([N4] Infortic) #12

Hola.

La ficha de proveedor debe de estar bloqueada por alguna razón.

El comando:

Modificar ficha seleccionada con formulario

Es puñetero pues inicia una transacción que bloquea las fichas, intenta ejecutar el formulario por medio de una acción con lanzar acción, puedes crear una variable global con el ID del pedido y lanzar una accion que lance un proceso que carga el pedido desde dicha variable global y a continuación lance el formulario, de esta forma no se iniciará la transacción.

Con esto puedes probar si el problema está en el comando de modificar con formulario.

También debes revisar si actualizas la ficha del proveedor desde dos tablas a la vez (por ejemplo desde la cabecera y las líneas) eso me ha dado problemas a veces también.


([N4] rpaton) #13

Hola:

Lo curioso del caso es que ni el proveedor tiene actualizaciones y ninguna actualización graba en el proveedor. Solo ocurre cuando creas el registro por primera vez y añades las líneas de detalle. Después no se ve afectado el funcionamiento. Es decir, que si das el alta y no añades líneas y vuelves a editar el pedido si lo hace bien.

Estoy preparando un .VIN para soporte para que vean el funcionamiento y qué alternativas puedo tener.

Saludos.

Ricardo Patón


([N4] Infortic) #14

Eso es porque cuando lo vuelves a abrir, no lo haces con:

Modificar ficha seleccionada con formulario

sino haciendo doble click en la rejilla que te lanza el formulario de modificación al igual que si lo hicieras con una acción.

Tiene sentido que se bloquee sólo la primera vez, por cómo lo abres la primera vez.

Prueba lo que te he comentado, lo más probable es que no se te bloquee, eso sí, tendrás que ver otra forma de obtener el nº de documento, deberás hacerlo en el aceptar del formulario en lugar de hacerlo desde fuera como haces ahora.


([N4] rpaton) #15

Hola:

Para editar lo abro de la misma forma.


Manejador de Evento: EDITAR_FICHA
Cargar lista ( PED_CM@vTextilDat, ID, REG_SELEC, , , )
Seleccionar ficha por posición ( 1 )
Modificar ficha seleccionada con formulario ( PED_CM_EDITAR@vTextil, )


El problema surge cuando selecciono un proveedor cuando estoy dando el alta. Si no selecciono proveedor en la cabecera funciona perfectamente.

Saludos.
Ricardo Patón


([N4] Infortic) #16

Hola.

A mi dar altas así me ha dado problemas también, a veces con actualizadores, a veces el comando Interfaz: Guardar en alta o modificación no funcionaba si uso el comando “Modificar ficha seleccionada con formulario” para dar altas (esto me pasó la semana pasada).

Al final me en todos los casos me he cansado de hacer pruebas y lo he hecho lanzando el formulario con una acción como te comento y me ha funcionado, no sé si en tu caso funcionará.

Lo que es raro es el tema de con proveedor no va y sin proveedor si, no sé a es debido, es muy raro.

Comenta lo que te diga soporte, pues seguro que le pasa a alguien más en el futuro.


([N4] rpaton) #17

Hola:
Soporte ya ha recibido el .vin y lo está estudiando.
Cuando me digan algo lo comento.

Saludos

Ricardo Patón


([N4] rpaton) #18

Hola:
Esta es la respuesta de soporte y la registra como incidencia.

"Si en un proceso o evento editamos una ficha maestra mediante el comando “modificar ficha seleccionada con formulario”, sucede lo siguiente:

Si no modificamos ningún campo del maestro y creamos uno o varios registros plurales, si bien no se refresca el campo actualizado en el formulario, al aceptar la ficha y volver a editarla, veremos que el campo mantiene el valor correcto dado por las actualizaciones. Por eso, si no asignas proveedor, el registro queda correctamente actualizado.

Si hacemos eso mismo, pero modificamos algún campo del formulario del maestro, las actualizaciones se disparan pero, al guardar la ficha, se guardará con el valor que tuviese el campo actualizado en el formulario. Es decir, si al editar la ficha el campo que se actualiza desde el histórico vale 0, al guardar la ficha se guardará con valor 0. Por eso, al asignar un proveedor queda el campo actualizado con valor 0.

Te confirmamos que la incidencia está sido incluida en nuestro sistema de gestión de incidencias con el código de referencia: VELNEO-3009.


([N1] wikan) #19

Gracias por la respuesta, la cuestión es que me da que la próximo versión la tendremos para Septiembre-Octubre de nuevo, así que toca esperar para poder tener estas incidencias graves solucionadas.


([N2] Mgalvezh) #20

A ver si lo entiendo, supongamos que un registro recibe datos mediante una actualización, ejemplo total ventas cliente en la ficha de clientes, un usuario tiene la ficha abierta, si en ese momento se produce una actualización y el usuario por lo que sea modifica algún campo, digamos el tlfn ¿ no se produce la actualización? o he entendido mal ? (espero)

PD:ni caso, ya lo he releído con mas atención.

Saludos.
Miguel.